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ABSTRACT 


There  are  two  main  purposes  to  this  thesis  study.  First,  we  will  deploy  the 
principles  of  software  development  that  we  have  learned  at  NFS  and  test  its  validity 
through  the  development  of  a  real  world  system.  This  system  will  be  a  completely  self 
sustaining  prototype  of  a  web-based  interactive  military  uniform  regulation  manual. 
Second,  we  will  conduct  a  study  of  Human  Computer  Interaction  (HCI)  through  the 
design  and  usability  testing  of  the  new  interactive  uniform  regulations  manual.  All 
military  services  currently  possess  their  own  individual  uniform  regulations  specific  to 
each  service.  This  system,  although  specifically  designed  for  the  United  States  Marine 
Corps,  can  be  used  as  a  model  for  any  other  service  as  well  as  any  international  military 
desiring  a  similar  solution  to  the  inherent  problems  associated  with  current  manuals.  The 
new  system  will  address  all  aspects  currently  outlined  in  the  regulations.  This  regulation 
will  be  used  by  all  US  civilians  and  military  service  members  to  whom  the  current 
manual  is  now  relevant.  Although  we  fully  intend  to  deliver  a  finished  product  to  the 
Marine  Corps  for  their  official  use,  the  true  value  to  us  as  students  is  in  the  process  of 
developing  and  testing  this  new  system.  The  knowledge  learned  here  will  benefit  us  in 
any  future  system  design  or  development  projects. 
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I.  INTRODUCTION 


The  two  main  purposes  of  this  thesis  study  are  to  deploy  the  prineiples  of  software 
development  that  we  have  learned  at  NPS  and  test  their  validity  through  the  development 
of  a  real  world  system.  This  system  we  developed  is  a  completely  self  sustaining 
prototype  of  a  web-based  interactive  military  uniform  regulation  manual.  Second,  we 
conducted  a  study  of  Human  Computer  Interaction  (HCI)  through  the  design  and 
usability  testing  of  the  new  interactive  uniform  regulations  manual.  All  military  services 
currently  possess  their  own  individual  uniform  regulations  specific  to  each  service.  This 
system,  although  specifically  developed  for  the  United  States  Marine  Corps,  can  be  used 
as  a  model  for  any  other  service  as  well  as  any  international  military  desiring  a  similar 
solution  to  the  inherent  problems  associated  with  current  manuals.  The  new  system 
addresses  all  aspects  currently  outlined  in  the  regulations.  This  regulation  can  be  used  by 
all  US  civilians  and  military  service  members  to  whom  the  current  manual  is  now 
relevant.  Although  the  finished  product  is  ready  for  official  use  by  the  Marine  Corps,  the 
true  value  to  us  as  students  was  in  the  process  of  developing  and  testing  this  new  system. 
The  knowledge  learned  here  will  benefit  us  in  any  future  system  design  or  development 
projects. 

The  benefits  of  studying  the  iterative  process  of  software  development  are 
invaluable  to  any  Computer  Scientist.  In  our  capacity  as  military  officers,  whether  in  the 
US  Military  or  the  German  Armed  Forces,  we  will  be  involved  in  the  development  of 
new  military  software  systems.  Whether  it  is  as  procurement  officers,  advisors,  or  full 
project  managers,  we  will  need  to  possess  the  skills  inherent  to  software  development. 
Regardless  of  the  role,  the  experience  necessary  to  handle  the  intricacies  required  in 
software  development  is  difficult  to  acquire.  We  will  be  confronted  with  situations  that 
require  close  interaction  with  civilian  contractors  who  already  have  years  of  experience  in 
this  field.  We  will  need  to  have  a  skill  set  to  assess  the  functionality  of  proposed  systems 
and  intelligently  challenge  the  contractors.  This  thesis  will  allow  us  the  best  opportunity 
to  develop  these  skills  in  the  most  expeditious  manner. 
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The  scope  of  this  thesis  was  to  create  an  easy  to  use  web-based  graphical  user 
interface  (GUI)  based  uniform  regulation  guide  along  with  the  design  and  creation  of  a 
server  required  to  house  such  a  web  site.  The  guide  was  implemented  using  primarily 
visual  aides  and  follows  the  practices  of  good  Macro/Micro  Human  Computer  Interaction 
(HCI)  Design.  The  aim  was  to  provide  the  needed  information  to  the  user  in  an  intuitive 
GUI  interface  that  requires  minimal  “mouse  clicks”  to  retrieve  the  desired  information 
and  we  feel  that  we  have  satisfied  that  requirement.  The  guide  also  provides  the  user 
with  alternative  text  from  the  current  regulations  manual  dealing  with  the  specific 
uniform  in  question.  The  end  result  is  an  easy  to  use  research  tool  that  may  be  utilized  by 
any  Marine  to  ensure  that  their  uniform  is  within  regulations.  Our  anticipated  server 
requirements  were  to  develop  a  system  that  was  self  contained  and  independent  of 
existing  hardware/software  requirements  of  the  proposed  client  group.  For  that  purpose, 
we  specifically  used  the  open  source  software  Apache  HTTP  Web  servers,  PHP  (> 
version  4),  and  MySQL.  Our  design  allows  the  client  side  to  use  any  available  web 
browser. 

The  documentation  provided  here  details  our  research  and  progress  for  this 
project.  In  Chapter  II  we  provide  background  information  of  the  current  problems  with 
the  existing  Marine  Corps  uniform  regulations  manual.  We  detail  how  we  intend  to  meet 
the  needs  of  the  intended  users  of  this  new  system.  We  also  provide  some  general 
background  information  regarding  the  Unified  Process  for  software  development  that  we 
followed  throughout  development  of  this  application.  We  chose  to  follow  the  Unified 
Process  mainly  because  it  is  the  state-of-practice  in  today’s  software  industry,  which  was 
taught  to  us  here  at  NPS,  and  it  is  the  process  that  we  felt  most  comfortable  with.  In  this 
chapter,  we  outline  the  Unified  Process  with  particular  emphasis  on  the  importance  of  use 
cases.  We  end  the  chapter  with  a  close  look  at  HCI  and  the  concerns  associated  with 
good  web  design  from  an  aesthetic  point  of  view. 

Chapter  III  is  where  we  provide  a  detailed  account  of  our  journey  through  this 

entire  process.  We  breakdown  the  Inception  Phase,  the  Elaboration  Phase,  the 

Construction  Phase,  and  the  Transition  Phase  and  discuss  how  we  approached  each  phase 

within  the  framework  of  the  Unified  Process.  Here  you  will  find  how  we  created  our  use 

cases  and  how  we  fully  developed  our  requirements  for  this  site.  Our  complete 
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Requirements  Document  can  be  found  in  Appendix  I  but  we  summarize  it  in  Chapter  III. 
We  also  outline  our  design  strategy  which  puts  us  into  the  Elaboration  Phase.  During  this 
phase  we  mapped  out  our  ideas  for  a  design  that  will  meet  the  specific  requirements  of 
the  Inception  Phase.  We  again  summarize  our  System  Design  Specification  which  can  be 
found  in  Appendix  II.  In  Chapter  III  we  also  discuss  our  security  measures,  evolution, 
risk  analysis,  and  our  approach  to  the  HCI  issues  outlined  in  Chapter  II. 

In  Chapter  IV  we  detail  the  testing  phases  of  the  prototype.  We  conducted  three 
formal  rounds  of  testing  with  three  different  populations.  Our  testing  audience  grew  with 
each  round  as  well  as  the  functionality  of  the  application  during  the  tests.  Chapter  V 
concludes  our  work  with  a  look  at  future  work  still  left  to  be  done  in  this  area. 

It  is  important  to  keep  in  mind  that  although  we  were  able  to  create  a  valuable 
product  that  serves  a  needed  purpose  for  the  Marine  Corps,  it  is  the  process  and  not  the 
product  that  is  the  focus  of  this  thesis.  There  are  countless  books  and  web  sites  available 
to  offer  guidance  on  practices  for  good  web  site  development.  In  our  research,  we 
discovered  that  the  majority  of  these  references  only  cover  the  aesthetics  of  web  design 
and  deal  primarily  with  efficient  layouts  of  web  pages.  The  focus  is  on  the  product  and 
neglects  to  give  solid  details  of  the  process  required  for  effective  web  design.  In  today’s 
enormous  e-commerce  market,  web  sites  that  are  being  built  are  extremely  complicated 
and  intricate  and  rival  the  complexities  of  a  large  software  development  project.  We  can 
find  several  types  of  software  development  processes,  one  of  which  is  the  Unified 
Process  followed  here,  that  are  currently  being  used  to  help  software  developers  navigate 
through  developing  software  systems.  The  software  engineering  discipline  is  focused  on 
improving  the  software  development  process  to  allow  for  on-time  and  on-budget  software 
but  there  lacks  the  same  guidance  for  the  web  site  development  process.  This  lack  of 
regulation  is  puzzling  since,  after  all,  web  sites  are  software  and,  with  the  growing 
functionality  found  in  today’s  web  sites,  suffer  the  same  shortfalls  of  software  such  as 
budget  and  schedule. 

We  have  attempted  to  prove  our  point  that  since  web  sites  behave  exactly  like 
software,  they  should  be  able  to  be  developed  with  the  same  process.  We  attempted  to 
use  the  well  known  Unified  Process  for  complex  software  system  development  and 
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develop  a  complex  web  site  with  it.  Our  approach  was  to  follow  the  Unified  Process 
learned  here  at  the  Naval  Postgraduate  School  as  closely  as  possible  and  use  it  in 
developing  a  web  based  uniform  regulations  manual  for  the  United  States  Marine  Corps. 
We  took  a  rather  large  liberty  in  that  our  team  played  both  the  role  as  developer  and 
customer.  We  did  not  officially  involve  the  United  States  Marine  Corps  in  developing 
this  site  since,  again,  it  was  the  process  that  was  our  main  interest.  Since  one  of  our 
thesis  members  is  a  US  Marine,  we  felt  that  we  could  adequately  play  both  roles  and  still 
accomplish  our  goal  of  this  thesis.  We  thoroughly  tested  the  web  site  on  active  duty 
Marines,  as  described  in  Chapter  IV  of  this  document,  so  we  feel  confident  that  we 
accurately  represented  the  intended  users  of  this  site.  This  document  states  our  results. 
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II.  BACKGROUND 


A.  INTRODUCTION 

The  current  official  Marine  Corps  Uniform  Regulations  Manual  is  available  in 
hardcopy  or  PDF  only.  There  are  some  web  based  manuals  that  can  be  found  on  the 
internet  but  none  of  them  are  designated  as  an  “official”  source  for  information  by 
Headquarters  Marine  Corps.  There  is  not  a  Graphical  User  Interface  system  currently  in 
existence  for  this  information,  and  in  its  current  form,  the  manual  is  not  well  written  in  an 
easy  to  use  manner. 

Major  issues/concerns  with  the  existing  manual: 

•  Different  services  have  different  manuals;  there  is  no  “single-instance” 
access  available  covering  all  services. 

•  Manuals  may  require  multiple  pages  to  be  repeatedly  referenced  before 
being  fully  understood. 

•  Verbiage  can  be  distracting  and  cause  regulations  to  be  misunderstood. 

•  It  does  not  provide  a  “quick  reference”  for  user  convenience. 

•  Changes  to  regulations  require  entire  manuals  to  be  generated  and 
replaced,  leading  to  older  versions  with  outdated  materials  still  in 
circulation. 

•  Not  written  to  be  “user  intuitive”. 

•  Even  experienced  users  can  have  problems  quickly  accessing  the 
information  they  require. 

•  The  following  is  a  list  of  items  that  must  be  supported  in  order  for  our 
system  to  properly  meet  the  needs  of  current  users: 

•  Reference  uniform  components  and  items  for  the  prescribed  uniform  of 
the  day  (e.g.  what  comprises  Service  Dress  Bravo?) 

•  Reference  allowed  locations  to  wear  a  particular  uniform  (e.g.  Cammies 
not  allowed  off  base  for  Marines) 

•  Identification  of  medals  and  ribbons 

•  Reference  order  of  precedence  for  medals  and  ribbons 

•  Identification  of  all  uniform  insignia 

•  Identify  correct  location  for  all  uniform  insignia  as  well  as  for  medals  and 
ribbons 
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•  Identify  correct  location  for  uniform  components  (e.g.  proper  wearing  of 
cover,  proper  length  of  tie  or  pant  leg) 

•  Reference  any  accessories  allowed  and  their  proper  wear  or  usage  (e.g. 
purse  or  umbrella) 

•  Reference  proper  grooming  standards 

•  Miscellaneous  uniform  issues 

B,  UNIFIED  PROCESS 

The  Unified  Process  is  a  popular  iterative  and  incremental  software  development 
process.  It  should  be  viewed  more  as  a  framework  which  can  be  customized  for  specific 
software  development  projects.  According  to  (Brugee  and  Dutoit,  2003) 

The  unified  process  distinguishes  important  time  ranges  called  “cycles”  in  the 
lifetime  of  a  software  system.  Note  that  these  are  different  from  the  cycles  in  the  spiral 
model;  they  can  be  thought  of  as  characterizing  the  stage  of  maturity  of  the  software 
system  during  its  lifetime... A  cycle  generally  ends  with  a  release  of  the  system  as  a 
product  to  the  customer.  Each  cycle  can  be  in  one  of  four  states  called  phases:  Inception, 
Elaboration,  Construction,  and  Transition. 

All  four  phases  are  divided  into  a  series  of  time  driven  iterations  that  can  be 
revisited  after  the  process  has  started.  Each  iteration  results  in  an  increment,  which  is  a 
release  of  the  system  that  contains  added  or  improved  functionality  compared  with  the 
previous  release.  Eigure  I  shows  how  the  relative  emphasis  of  different  disciplines 
changes  over  the  course  of  a  project.  Although  most  iterations  will  include  work  in  most 
of  the  process  disciplines  (e.g.  Requirements,  Design,  Implementation,  Testing)  the 
relative  effort  and  emphasis  will  change  over  the  course  of  the  project. 
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Figure  1.  Unified  Process 

The  following  is  a  brief  synopsis  of  each  phase  based  on  The  Unified  Process 
explained  by  (Scott,  2001): 

Inception  Phase: 

Inception  is  the  smallest  phase  in  the  project,  and  ideally  it  should  be  quite  short. 
If  the  Inception  Phase  is  long  then  it  is  usually  an  indication  of  excessive  up-front 
specification,  which  is  contrary  to  the  spirit  of  the  Unified  Process. 

The  following  are  typical  goals  for  the  Inception  phase. 

•  Establish  a  justification  or  business  case  for  the  project 

•  Establish  the  project  scope  and  boundary  conditions 

•  Outline  the  Use  Cases  and  key  requirements  that  will  drive  the  design 
tradeoffs 

•  Outline  one  or  more  candidate  architectures 

•  Identify  risks 

•  Prepare  a  preliminary  project  schedule  and  cost  estimate 

The  Eifecycle  Objective  Milestone  marks  the  end  of  the  Inception  phase. 
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Elaboration  Phase: 


During  the  Elaboration  phase  the  projeet  team  is  expeeted  to  eapture  a  healthy 
majority  of  the  system  requirements.  However,  the  primary  goals  of  Elaboration  are  to 
address  known  risk  faetors  and  to  establish  and  validate  the  system  arehiteeture. 

The  arehiteeture  is  validated  primarily  through  the  implementation  of  an 
Exeeutable  Arehiteeture  Baseline.  This  is  a  partial  implementation  of  the  system  whieh 
ineludes  the  eore,  most  arehiteeturally  signifieant,  eomponents.  It  is  built  in  a  series  of 
small,  timeboxed  iterations.  By  the  end  of  the  Elaboration  phase  the  system  arehiteeture 
must  have  stabilized  and  the  executable  architecture  baseline  must  demonstrate  that  the 
architecture  will  support  the  key  system  functionality  and  exhibit  the  right  behavior  in 
terms  of  performance,  scalability  and  cost. 

The  final  Elaboration  phase  deliverable  is  a  plan  (including  cost  and  schedule 
estimates)  for  the  Construction  phase.  At  this  point  the  plan  should  be  accurate  and 
credible  since  it  should  be  based  on  the  Elaboration  phase  experience  and  since 
significant  risk  factors  should  have  been  addressed  during  the  Elaboration  phase. 

The  Lifecycle  Architecture  Milestone  marks  the  end  of  the  Elaboration  phase. 

Construction  Phase: 

Construction  is  the  largest  phase  in  the  project.  In  this  phase  the  remainder  of  the 
system  is  built  on  the  foundation  laid  in  Elaboration.  System  features  are  implemented  in 
a  series  of  short,  timeboxed  iterations.  Each  iteration  results  in  an  executable  release  of 
the  software. 

The  Initial  Operational  Capability  Milestone  marks  the  end  of  the  Construction 

phase. 

Transition  Phase: 

The  final  project  phase  is  Transition.  In  this  phase  the  system  is  deployed  to  the 
target  users.  Eeedback  received  from  an  initial  release  (or  initial  releases)  may  result  in 
further  refinements  to  be  incorporated  over  the  course  of  several  Transition  phase 
iterations.  The  Transition  phase  also  includes  system  conversions  and  user  training. 
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The  Product  Release  Milestone  marks  the  end  of  the  Transition  phase. 

It  is  important  to  remember  that  the  Unified  Process  described  above  is  designed 
to  be  tailored  to  the  needs  of  the  project.  It  is  only  a  framework  that  provides  loose 
guidance  for  developing  a  software  system  but  is  structured  enough  to  clearly  define  each 
phase  and  desired  goals  of  each. 

C.  CURRENT  PROBLEMS  WITH  WEB  DESIGN 

One  of  the  biggest  problems  with  any  software  development  is  clearly  stating  and 
understanding  the  user’s  needs.  There  are  several  factors  that  lead  to  problems  with 
clearly  defining  system  requirements,  which  have  been  the  subject  of  much  research,  but 
we  are  going  to  focus  on  the  disconnect  between  client  and  designer  in  the  requirements 
stage.  Web  design  suffers  from  this  problem  in  that  projects  are  delayed  due  to  a  lack  of 
understanding  during  the  requirements  stage  and  our  research  here  attempts  to  explore  a 
possible  solution. 

Poor  understanding  of  target  user  needs  or  a  client’s  vision,  ineffective  use  of 
limited  resources,  misguided  emphasis  on  the  wrong  design  priorities,  over-emphasis  on 
technologies  all  will  contribute  to  a  failed,  late,  inappropriate  or  too-expensive  website. 
Experience  can  teach  us  how  to  avoid  pitfalls,  but  the  greatest  lesson  can  be  learned  by 
the  least  experienced;  the  earlier  that  purpose  and  goals  are  clearly  defined  and  recorded, 
the  more  easily  problems  are  identified  and  solved,  the  easier  it  is  to  stay  focused,  and  the 
better  the  result  is  for  everyone. 

Somewhat  surprisingly,  web  developers  seem  reluctant  to  adopt  methods  and 
approaches  from  other  disciplines  that  could  reduce  their  problems.  Particularly  during 
the  crucial  initial  phase  of  projects,  web  design  can  benefit  from  emulating  certain 
software  engineering  practices,  including  the  Unified  Process.  (Cockburn,  2001) 

D,  INTRODUCING  USE  CASES 

Use  cases  provide  a  simple,  fast  means  to  decide  and  describe  the  purpose  of  a 
project.  They  are  successfully  employed  by  many  software  engineers  as  a  way  to  capture 
the  high-level  objectives  of  an  application  during  the  initial  phase  of  development.  There 
is  no  reason  that  web  site  developers  should  not  also  benefit  from  a  use-case  driven 
approach.  Even  a  project  that  initially  seems  straightforward  can  balloon  into  an 
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unmanageable  behemoth  if  the  purpose  is  not  always  at  the  forefront  of  development.  To 
define  a  project’s  use  cases,  we  need  to  consider  two  concepts,  and  how  they  relate: 

•  the  actors 

•  the  goals 

Actors  are  everyone  and  everything  that  will  use,  or  be  used,  by  the  system.  It 
should  be  noted  here  that  “system”  is  being  used  to  describe  the  generic  idea  of  use  cases 
but  in  the  context  of  our  thesis,  “system”  and  “web  site”  are  interchangeable.  Goals  are 
what  one,  some,  or  all  of  the  actors  want  to  achieve.  To  be  complete,  every  use  case  must 
describe  a  specific  goal  and  the  actors  that  will  perform  tasks  to  achieve  that  goal. 
(Larman,  2004) 

The  actors  are  external  to  our  system  so  we  cannot  control  their  behavior  or  inputs 
but  we  can  make  certain  assumptions  about  what  is  expected  from  an  actor  to  achieve  a 
goal.  The  most  obvious  actor  in  the  case  of  any  website  is  a  visitor  to  the  site  which  in 
our  case,  our  expected  users  are  U.  S.  Marines.  We  assume  that  the  actors  are  visiting 
our  site  to  attain  information  about  some  part  of  their  uniform  but  in  general,  users  visit 
sites  for  several  reasons,  depending  on  the  purpose  of  the  web  site.  Actors  are  not 
necessarily  human,  as  seen  in  our  Requirements  Document  found  in  Appendix  I,  we  have 
included  the  database  as  an  “actor”.  Whatever  our  vision,  use  cases  will  describe  the 
goals  achieved  by  actors  who  perform  tasks. 

1.  An  Example  of  Use  Cases 

A  weblog  enables  its  owners  to  communicate  thoughts  about  a  topic  and  others  to 
read  them  and  perhaps  respond.  The  obvious  weblog  actors  are  the  authors  and  the 
visitors  to  the  web  log.  The  author  plays  the  role  of  generating  the  content  and  the  visitor 
plays  the  role  of  reading  the  content  and  responding.  The  goals  are  to  inform  and  to  be 
informed. 

After  a  little  brainstorming,  we  could  decide  that  some  of  these  actors’  tasks 
should  include  reading  an  item,  creating,  editing,  and  deleting  blog  content,  commenting, 
syndicating,  and  some  administrative  tasks,  such  as  controlling  access,  permissions,  and 
accounts.  Some  of  these  tasks  are  common  to  all  actors  and  some  may  be  exclusive  to  a 
single  actor.  All  of  them  can  be  encapsulated  in  a  use  case  that  describes  our  initial  idea: 
“Publish  Weblog”. 
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This  use-case  diagram  illustrates  the  relationship  between  actors  and  goals: 


—  -  -  -  Publish  Weblog  ^  - - 

Visitor  Author 


Figure  2.  Use  case  Diagram 

Use-case  diagrams  make  it  easier  to  think  about  the  relationships  or  dependencies 
between  use  cases  and  actors.  Perhaps  visitors  and  authors  would  like  to  be  able  to 
search  for  particular  content  already  published  in  the  weblog: 


visitor 


Publish  Weblog 


Search  Content 


Author 


Figures.  Use  case  Diagram 

Both  visitors  and  authors  want  to  be  able  to  search.  Furthermore,  it  is  not  possible 
to  search  for  content  that  has  not  yet  been  published.  The  “Search  Content”  use  case  is 
therefore  dependant  upon  “Publish  Weblog”. 

Suppose  we  decided  to  employ  Google  for  our  searching  function.  Google 
becomes  an  actor  and  the  “Search  Contend’  use  case  is  dependent  upon  Google. 
Google’s  task  as  an  actor  is  to  deliver  search  results. 
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Publish  Weblog 


Visitor 


'  ic'‘ 

Search  Content 


Author 


Google 


Figure  4.  Use  ease  Diagram 

By  now  we  have  already  identified  some  of  the  aetors  involved  with  our  weblog, 
the  goals  they  are  trying  to  aehieve  and  some  dependeneies  between  them.  We  ean 
eonsider  this  a  high-level  eoneeptual  arehiteeture  of  our  site,  whieh  will  be  useful  when 
making  design  deeisions  later.  (Coekbum  2001) 

2,  The  Main  Benefit  of  Use  Cases 

The  erueial  benefit  of  use  eases  is  the  way  they  encourage  a  directed  method  of 
considering  project  requirements.  From  the  very  beginning,  we  are  designing  a  product 
by  concentrating  upon  the  needs  and  wants  of  those  who  will  use  it. 

As  with  any  foundation,  the  better  our  understanding  of  the  use  cases,  the  easier, 
more  focused,  and  more  appropriate  will  be  the  work  that  follows.  Use  cases  are  the 
context  that  allows  us  to  easily  picture  where,  within  a  project’s  life,  a  particular  element 
will  fit,  thus  promoting  clearer  decision-making  throughout  design  and  development. 
The  purpose  of  describing  use  cases  is  emphatically  not  to  fully  specify  the  exact  nature 
of  what  a  new  site  will  contain  and  how  it  is  to  be  built.  Instead,  use  cases  define  goals 
and  purpose;  the  problems  we  are  trying  to  solve.  Establishing  these  goals  lays  the 
foundation  for  the  scope  that  will  follow.  Additionally: 

•  If  we  simply  consider  the  roles  played  by  the  actors  and  their  goals,  the 
use-case  model  can  very  rapidly  emerge. 
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•  Use-case  diagrams  can  distill  a  complex  project  into  a  more  easily 
comprehensible  picture. 

•  A  well-constructed  use-case  model  can  be  understood  by  all  the 
stakeholders  in  a  project:  developers,  managers  and  clients.  It  is  a 
powerful  aid  to  collaborative  development. 

•  Use  cases  ensure  that  scope  is  under  control  from  the  outset.  The 
identification  of  use  cases  and  their  dependencies  makes  it  easy  to 
distinguish  between  core  goals  that  must  be  satisfied  and  subsidiary 
enhancements  that  may  be  postponed.  Scoping  in  this  manner  allows  for 
better  planning  and  prioritization. 

•  There  is  no  consideration  toward  implementation  so  use  cases  can  be 
explored  without  restriction.  No  assumptions  about  tools  and  technologies 
are  made,  nor  should  they  be. 

Use-case  driven  development  is  a  mindset,  as  much  as  it  is  a  technique.  By 
emphasizing  the  actors  and  what  they  wish  to  achieve,  project  teams  can  advance  with 
greater  confidence  and  clarity.  A  solid  early  foundation  of  understanding  amongst  all 
concerned  allows  more  rapid  decision-making  later  on,  and  encourages  a  continual  focus 
on  the  project’s  true  purpose.  This  is  not  to  say  that  use  cases  were  the  only  tools  we 
used  to  create  our  site.  We  used  several  other  tools  that  are  described  below  but  it  is  the 
use  case  that  is  the  foundation  of  the  requirements  portion  of  the  Inception  Phase.  From  a 
complete  list  of  use  cases  we  were  able  to  clearly  visualize  the  requirements  and 
functionality  of  this  web  site.  The  use  cases  proved  to  be  our  most  valuable  tool  in 
development  due  in  large  part  to  the  unrestricted  nature  of  creating  a  use  case.  Our  use 
cases  became  a  “wish  list”  and  we  later  tailored  the  use  cases  as  we  explored  capabilities 
within  the  design  stage. 
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III.  SYSTEM  DEVELOPMENT 


A.  OUR  APPROACH 

For  this  project,  our  team  followed  the  guidelines  of  the  Unified  Process  but  we 
also  tailored  the  process  of  development  as  we  found  appropriate.  We  were  able  to 
complete  the  Inception  Phase,  the  Elaboration  Phase,  and  the  Construction  Phase.  The 
Transition  Phase  is  still  ongoing. 

1,  Inception  Phase 

We  documented  our  work  in  the  Inception  Phase  with  a  complete  Requirements 
Document  which  is  found  in  Appendix  I.  In  developing  our  Requirements  Document,  we 
initially  focused  our  efforts  on  developing  use  cases  as  described  above.  The 
Requirements  Document  includes  a  flow  chart  of  information  paths,  use  case  diagrams, 
use  cases,  system  sequence  diagrams,  a  list  of  the  required  options  for  the  home  page 
along  with  a  detailed  diagram  of  each  selection,  and  a  decision  tree  to  visually  display  the 
options  necessary  to  choose  a  uniform  display.  We  were  initially  uninhibited  in  our 
initial  use  case  declarations  but  we  later  reviewed  our  use  cases  and  tailored  our  list  based 
on  feasibility  and  time  constraints  of  this  project.  We  then  quickly  developed  the 
boundary  use  cases  and  the  use  case  diagrams  that  are  simply  a  sketch  of  the  actors 
involved  in  each  use  case. 

For  each  use  case,  we  developed  a  sequence  diagram,  which  is  another  tool 
associated  with  the  Unified  Process.  Sequence  diagrams  “represent  the  objects 
participating  in  the  interaction  horizontally  and  time  vertically.”  (Brugee  and  Dutoit, 
2003)  We  used  the  sequence  diagrams  to  detail  the  viability  of  our  use  cases  and 
determine  whether  a  system  could  actually  support  the  functionality  described  in  the  use 
case. 

We  also  relied  heavily  on  flow  charts  in  the  Inception  Phase.  These  flow  charts 
allowed  us  to  clearly  visualize  and  plan  for  the  various  options  that  would  be  found  in 
this  site.  This  tool  proved  to  be  invaluable  to  us  since  these  charts  lead  us  directly  into 
the  Elaboration  Phase.  We  were  able  to  map  out  the  log  in  procedures  and,  more 
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importantly,  we  mapped  out  the  home  page  selections.  It  is  these  selections  that  drove 
the  entire  design  process  since  this  functionality  was  vitally  important  to  the  site  and  was 
the  reason  behind  the  entire  concept. 

Throughout  the  Inception  Phase,  we  found  it  valuable  to  constantly  remind 
ourselves  of  the  intended  audience  of  this  system.  This  system  will  be  relied  on  by 
Marines  world  wide  as  an  accurate  source  of  standards  that  ensure  their  compliance  with 
the  Marine  Corps  Order.  The  new  system  needs  to  address  all  aspects  currently  outlined 
in  the  regulations,  such  as  proper  wearing  of  the  uniform,  grooming  standards,  ribbon  and 
medal  precedence,  civilian  attire,  PT  gear,  and  optional  items  for  male  and  female 
officers  and  enlisted  U.  S.  Marines.  This  system  could  also  be  used  by  all  US  civilians 
and  military  service  members  to  whom  the  current  manual  is  now  relevant.  Keeping  the 
audience  at  the  forefront  through  the  Inception  Phase  is  vital  to  scoping  the  size  and 
functionality  of  the  system  being  developed. 

As  stated  earlier,  our  team  assumed  the  role  of  the  client  during  this  project.  One 
of  our  team  members  is  a  U.  S.  Marine  so  we  had  an  intended  user  working  on  the 
development  of  this  system.  We  still  felt  it  necessary  to  conduct  a  user  analysis  in  order 
to  attempt  to  capture  the  characteristics  of  our  users  and  to  help  us  narrow  the  necessary 
functionality.  We  concluded  that  the  user  population  would  be  widely  varied  in 
education  (civilian  and  professional),  computer  savvy,  age,  and  cultural  background. 
Interaction  with  the  GUI  interface  to  the  system  needs  to  be  intuitive  for  the  user  with  a 
high  school  background  and  minimal  computer  skills  while  simultaneously  not  alienating 
the  more  educated  user  population.  Additionally,  implementing  multimedia  suitable  and 
appealing  for  both  the  young  and  older  users  proved  arduous.  Finally,  in  order  to  avoid 
confusion,  we  needed  to  be  vigilant  in  our  usage  of  terminology  (especially  acronyms) 
that  is  only  prevalent  in  certain  cultures. 

The  expected  users  of  this  system  include  all  members  of  the  U.S.  Marine  Corps 
as  well  as  any  other  military  members  desiring  information  regarding  Marine  Corps 
uniforms.  Users  may  also  include  civilians  requiring  the  same  information.  The 
expected  users  will  range  from  Marines  with  very  little  military  experience  to  career 
Marines  whom  have  dedicated  a  lifetime  to  the  Marine  Corps  and  are  well  versed  in  the 
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current  uniform  regulations  as  well  as  past  versions  of  the  manual.  This  system  must 
satisfy  the  needs  of  a  Marine  who  is  new  to  the  Marine  Corps  as  well  as  the  veteran.  It  is 
vital  that  the  information  provided  be  aeeurate  and  eorreet  in  order  to  prevent  the  user 
from  wearing  a  uniform  or  uniform  item  against  current  poliey. 

This  system  needs  to  incorporate  simplieity  within  its  design.  The  initial  design 
will  be  under  the  assumption  that  the  user  has  basie  eomputer  operating  skills  and  web 
browsing  eapabilities.  Where  applieable,  the  system  should  hide  system  complexity  from 
the  noviee  while  simultaneously  appealing  to  the  expert  user.  No  additional  skill  sets 
were  assessed  as  being  required  for  successful  operation  of  the  system.  The  majority  of 
interaction  the  user  will  have  with  the  system  will  involve  “point  and  click”  functionality. 

The  following  are  major  system  operations  derived  from  the  use  cases  found  in 
Appendix  I. 

•  Prospeetive  user  should  be  able  to  ereate  a  user  name  and  password  to 
access  the  site  and  set  aeeount  information. 

•  Prospeetive  user  should  be  able  to  log-in  to  the  system  with  a  user  name 
and  password  or  enter  the  system  as  a  guest. 

•  Prospeetive  user  should  be  able  to  update  aeeount  information  that  is 
currently  stored  in  the  data  base. 

•  User  should  be  able  to  seareh  for  a  uniform  authorized  for  own  rank. 

•  User  should  be  able  to  gather  information  and  photos  on  uniform 
regulations  for  ranks  or  genders  other  than  his  own. 

•  User  should  be  able  to  aecess  grooming  standards  for  a  male  or  female. 

•  User  should  be  able  to  see  awards  displayed  in  order  of  precedence  for 
their  own  awards  or  entered  awards. 

•  User  should  be  able  to  view  regulations  for  civilian  clothes. 

•  User  should  be  able  to  view  regulations  for  Physical  Training  (PT)  gear. 

•  User  should  be  able  to  view  regulations  for  organizational  elothing. 

The  boundary  use  eases  found  in  Appendix  I  identify  the  neeessary  set  up 
required  for  initial  system  functionality.  The  boundary  use  eases  ean  be  summarized  as 
follows: 

•  The  system  must  allow  an  administrator  to  put  a  new  file  into  the  system. 

•  The  system  must  allow  an  administrator  to  edit  user  accounts  stored  in  the 
database. 
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•  The  system  must  allow  an  administrator  to  add  or  remove  an  award  from 
the  database. 

This  system  functions  as  a  web  server  capable  of  displaying  interactive  pages  to  a 
user  with  containing  text  as  well  as  images.  The  web  server  needs  to  interact  and 
exchange  information  with  a  database  which  holds  user  account  information  as  well  as 
images  to  be  used  and  displayed  by  the  server  at  the  request  of  the  user.  Appendix  I 
shows  high  level  sequence  diagrams  that  illustrate  the  interaction  between  the  user,  the 
system  and  the  database  for  the  use  cases  given. 

2.  Elaboration  Phase 

The  main  documentation  that  captures  our  work  during  the  Elaboration  Phase  is 
the  Software  Design  Specification  found  in  Appendix  II.  The  purpose  of  the  Software 
Design  Specification  is  to  describe  the  functionality  of  the  Web  Based  Uniform  Manual. 
This  document  describes  the  subsystems  and  modules  that  form  the  Graphical  User 
Interface,  Web  Server,  and  Database.  The  Software  Design  Specification  provides  highly 
detailed  technical  data,  system  information,  and  other  relevant  information  on  the  Web 
Based  Uniform  Manual.  This  document  includes  an  architecture  diagram,  a  design  class 
diagram,  interaction  diagrams,  state  diagrams,  and  a  glossary. 

Of  course  the  goal  of  any  system  design  is  to  satisfy  the  requirements  given  by  a 
client  but  more  than  that  is  to  provide  a  system  that  will  be  easily  used  by  the  intended 
audience.  What  good  is  a  system  that  meets  all  of  the  functional  requirements  if  it  is  too 
difficult  for  anyone  to  use?  Our  goal  for  this  project  was  no  different.  The  guide  will  be 
implemented  using  primarily  visual  aides  and  follow  the  practices  of  good  Macro/Micro 
HCI  Design.  The  aim  was  to  provide  the  needed  information  to  the  user  in  an  easy  to  use 
GUI  interface  that  requires  minimal  “mouse  clicks”  to  retrieve  the  desired  information. 
The  guide  will  also  provide  the  user  with  alternative  text  from  the  Marine  Corps  Order 
P1020.34G  dealing  with  the  specific  uniform  in  question.  The  end  result  is  an  easy  to  use 
research  tool  that  may  be  utilized  by  members  of  the  United  States  Marine  Corps  to 
ensure  that  their  uniform  is  within  regulations. 

Our  Web  Based  Uniform  Regulations  Manual  is  organized  into  a  three-tier  closed 
architecture  composed  of  a  presentation  layer,  application  logic  layer  (domain),  and 
storage/network  layer  (services).  The  purpose  of  this  organization  is  to  promote  reuse, 
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support  distributed  processing,  and  allow  parallel  team  development.  Also,  by  building 
each  layer  only  in  terms  of  each  immediate  lower  layer,  this  design  will  reduce 
dependencies  between  each  layer  enabling  the  system  to  be  combined  with  other 
hardware/software  platforms  with  minimal  rewriting  of  single  layers. 

The  System  Architecture  decomposes  the  Web  Based  Uniform  Regulations 
Manual  system  into  subsystems  by  vertical  layers  and  horizontal  partitions.  The 
presentation,  domain,  and  service  top  layers  are  represented  by  the  common  graphical 
user  interface,  CTF  Infrastructure,  and  Computer  Website  services  subsystems 
respectively.  Figure  5  illustrates  the  organization  of  subsystem  layers  and  partitions 
within  the  Web  Based  Uniform  Regulations  Manual  System  Architecture. 
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Figures.  System  Architecture 


A  web  browser  will  function  as  the  client  interface.  Its  sole  purpose  is  the  display 
of  the  Web  server  generated  HTML  pages.  To  create  a  platform  independent  experience 
the  page  layout  will  be  controlled  by  Cascading  Style  Sheets.  These  style  sheets,  once 
cached  by  the  browser,  will  also  account  for  faster  webpage  loading.  All  content  creation 
will  be  done  by  server  side  PHP  scripting,  again  contributing  to  a  browser  independent 
display  without  the  need  for  client  side  browser  plug-ins  (like  Java  script),  thus  speeding 
up  the  page  load  time  and  avoiding  safety  critical  scripting  on  the  client  computer.  This 
will  also  allow  handheld  devices,  which  are  not  always  equipped  with  scripting  capable 
browser,  to  load  and  display  the  interface  pages. 
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Figure  6.  System  Context  Diagram 

The  middle  tier  is  divided  in  two  units  with  different  funetions,  an  intermediate 
layer  (web  server)  implemented  in  a  seripting  language  (PHP).  This  layer  reeeives 
requests  from  the  Internet  elients  and  generates  html  using  the  serviees  provided  by  the 
storage/infrastructure  layer.  This  additional  layer  provides  isolation  between  the 
applieation  layout  and  the  applieation  logie. 

This  system  is  designed  to  reside  on  an  Apaehe  Web  Server.  The  Apaehe  Web 
Server  has  several  advantages;  it  is  extremely  powerful,  modular,  flexible,  highly 
eonfigurable,  and  extensible.  It  is  freely  available  through  open  source  which  means  that 
its  source  code  is  examined  constantly  by  numerous  users.  This  constant  examination  by 
outsiders  makes  it  substantially  more  reliable  than  any  commercial  software  product  that 
can  only  rely  on  the  scrutiny  of  a  closed  list  of  employees.  Apache  currently  runs  on 
approx.  68-70%  of  all  web  servers  worldwide  making  it  the  #1  choice  of  web  servers 
since  1996  (Appu,  2002).  This  makes  it  the  most  secure  web  server  worldwide.  The 
information  on  this  site  needs  to  be  in  complete  compliance  with  Marine  Corps  Order 
P1020.34G.  Any  deviations  from  this  standard  render  this  site  useless.  The  threat  of 
hackers  is  always  present  when  dealing  with  the  web  based  systems.  If  any  user  can 
break  through  and  change  any  of  the  information  on  our  website,  it  will  sacrifice  the 
integrity  of  the  information  posted.  Once  the  information  is  found  to  be  inaccurate,  it 
will  render  our  system  unreliable  and  discourage  its  use.  Apache  provides  security- 
related  configuration  directives  enabling  administrators  to  tighten  the  security  (Appu, 
2002): 

•  User  /  Group:  Defines  user/group  Apache  should  run  as 

•  LimitRequestBody:  Restrict  total  size  of  HTTP  request  body  sent  from  a 
client 

•  LimitRequestFields:  Limit  number  of  HTTP  request  header  fields  that  will 
be  accepted  from  the  client 
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•  LimitRequestFieldSize:  Limit  size  of  the  HTTP  request  header  allowed 
from  the  client 

•  LimitRequestLine;  Limits  overall  size  of  the  HTTP  request  line  that  will 
be  accepted 

•  Listen;  Defines  the  IP  addresses  and  ports  the  server  listens  on 

•  ServerTokens:  Server  HTTP  response  header 

•  ServerSignature;  Content  of  footer  available  on  server-generated 
documents 

•  SSLEngine;  Toggle  usage  of  SSL/TLS  protocol  engine 

•  UserDir;  Indicates  the  location  of  user-specific  directories 

The  basic  design  philosophy  that  we  followed  was  to  create  four  complete  and 
separate  sites  that  can  actually  completely  stand  alone  and  have  a  common  link  from  the 
login  page  as  shown  in  Figure  7. 


Figure  7.  Overarching  Design 


This  type  of  architecture  allowed  us  to  extensively  test  while  developing  the  site. 
We  first  created  the  Male  Officer  “site”  in  its  entirety  and  tested  this  module.  Then  we 
created  the  login  page  and  developed  its  functionality.  Once  the  login  page  was  linked  to 
the  Male  Officer  “site”,  we  exhaustively  tested  this  smaller  system  and  developed  it 
completely,  as  described  in  Chapter  5  of  this  document.  Then  it  was  a  simple  duplication 
of  the  Male  Officer  “site”  in  order  to  create  the  Female  Officer  “site”,  the  Male  Enlisted 
“site”,  and  the  Female  Enlisted  “site”  (allowing  for  the  subtle  nuances  of  each 
subcategory).  The  final  step  in  architecture  design  was  to  link  all  four  subcategories  to 
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each  index  page.  For  example,  if  a  user  is  currently  in  the  Male  Officer  “site”  and  he 
desires  to  look  at  female  enlisted  uniforms,  he  can  quickly  access  the  index  page  of  the 
Female  Enlisted  “site”  and  navigate  through  that  “site”. 

All  four  subcategories  share  the  same  file  names  as  shown  in  Figure  7.  This 
allows  for  the  quick  creation  of  the  remaining  subcategories  after  the  first  one  was 
created.  This  type  of  file  naming  pattern  is  attainable  since  all  ranks  and  genders  within 
the  USMC  must  follow  the  same  manual.  Also  all  ranks  and  genders  within  the  USMC 
have  the  same  uniform  names  but  the  style  of  the  uniform  varies  between  ranks  and 
gender.  A  clear  and  concise  file  structure  is  imperative  for  construction  of  this  site  and  to 
ensure  maintainability.  All  files  needed  to  be  arranged  in  a  manner  that  was  easy  to 
follow  and  was  unambiguous  since  this  system  will  not  be  maintained  by  the  original 
design  team. 

All  files  are  placed  in  one  of  four  substructures  that  are  referenced  from  a  main 
index  page.  As  mentioned  above,  the  files  are  broken  up  into  four  main  categories;  male 
officer,  male  enlisted,  female  officer,  female  enlisted.  Figure  8  shows  the  file  structure 
for  male  officers.  This  structure  is  simply  repeated  for  all  other  categories. 
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Figure  8.  File  Structure 


3,  Construction  Phase 

The  construction  phase  is  where  we  actually  created  the  code  and  built  the  site. 
Part  of  the  code  is  provided  in  Appendix  V.  The  whole  site  is  coded  in  XFITML  1.0 
Transitional,  CSS  2.1  and  PFIP  5.  The  combination  of  XHTML,  CSS  and  PHP  was 
chosen  by  us  to  allow  for  an  easy  maintenance  of  the  website  and  represents  the  present 
time  open  source  standard  for  websites  that  include  server  side  scripting. 

A  main  CSS  style  sheet  controls  the  complete  layout  of  every  page.  So  global 
changes  to  adapt  the  layout  to  varying  requirements  are  simple  and  only  call  for  a  change 
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in  one  place,  the  main  CSS  style  sheet.  To  allow  style  and  layout  changes  to  single  pages, 
each  page  has  been  given  its  own  style  sheet  as  well. 

PHP  was  used  mainly  to  assemble  each  page  by  using  include  statements 
combined  with  validation  code.  The  content  of  each  page  is  separated  in  multiple  files 
that  contain  the  textual  information,  the  navigation  bars  and  buttons  and  the  images  used 
on  that  page.  This  design  was  chosen  to  allow  a  simple  implementation  of  changes  in  the 
original  uniform  manual  in  the  corresponding  web  page.  If  for  example  a  text  of  a  page  is 
changed  the  manger  of  the  site  only  needs  to  open  the  corresponding  file  containing  the 
text  to  be  changed.  By  structuring  the  pages  of  the  online  manual  this  way  the  possibility 
of  unintentional  changes  to  the  website  are  minimized.  Although  the  text  documents  are 
HTML  pages,  they  contain  only  the  most  necessary  markup  for  structuring  the  text.  This 
could  have  been  done  in  a  plain  text  file.  The  simple  HTML  markup  however  allows  for 
color  coded  syntax  highlighting  in  almost  every  text  editor  and  so  increases  the 
readability  of  the  text.  The  basic  structure  of  the  HTML  document  like  head  or  body  tags 
is  provided  and  needed  only  in  the  main  file  that  contains  the  include  statements. 

In  the  case  that  a  text  containing  document  or  an  image  is  removed  from  the  file 
structure  the  validation  code  co-located  with  the  include  statements  in  the  PHP  part  of  the 
page  will  ensure  that  the  page  is  still  displayed  without  any  problems  or  errors.  This 
allows  the  site  manager  to  remove  unwanted  or  outdated  contents  without  changes  in  the 
code  of  the  main  page.  The  generic  naming  of  the  files  also  allows  for  an  easy 
replacement  of  pages,  documents  or  pictures. 

The  top  and  left  navigation  bars  are  global  and  exist  only  in  one  place  for  each  of 
the  four  main  structures.  This  again  allows  for  simple  global  changes  should  additional 
links  be  required  or  target  URL’s  change. 

Although  research  into  client  side  scripting  technologies  like  Ajax  (McLaughlin, 
2006)  were  done,  server  side  scripting  was  chosen  to  allow  even  the  weakest  or  highly 
restricted  client  hardware  access  to  the  site.  Restrictions  like  low  computing  power  or 
disabling  of  JavaScript  for  security  reasons  have  no  effect.  The  only  thing  the  client 
hardware  needs  to  provide  is  some  kind  of  web  browser  that  is  capable  of  displaying 
XHTML  files.  The  combination  with  CSS  then  allows  a  styling  adapted  for  different 
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devices.  At  the  present  time  styling  for  mobile  devices  and  print  output  are  possible.  This 
styling  has  not  been  implemented  by  us  at  the  present  time  and  remains  at  the  discretion 
of  the  Marine  Corps. 

4.  Transition  Phase 

During  the  Transition  Phase  we  conducted  extensive  testing  which  is  described  in 
Chapter  5  of  this  document.  This  is  also  the  phase  where  the  system  is  deployed  to  the 
intended  user,  however,  as  of  the  writing  of  this  document,  we  have  yet  to  complete  this 
portion.  It  is  our  intention  to  travel  to  Headquarters  Marine  Corps  in  Quantico,  VA  to 
present  this  project.  It  is  our  hope  that  the  Marine  Corps  will  find  our  site  valuable  and 
will  host  the  site  on  its  web  servers.  This  is  a  secondary  goal  of  this  thesis,  with  the 
primary  goal  being  to  study  how  the  Unified  Process  could  be  implemented  in  web  site 
design.  The  success  of  our  site  within  the  Marine  Corps  is  irrelevant  to  this  thesis  and  is 
not  covered  here. 

B,  RISK  ANALYSIS 

1,  Risk  Management  Plan 

Our  risk  management  plan  can  be  summed  up  in  the  following: 

•  Identify  Risk 

•  Assess  Risk 

•  Assess  Likelihood 

•  Determine  Risk  Mitigation 

•  Assess  Final  Risk  Cost 

•  Adjust  Project 

To  identify  risk  our  team  did  some  simple  brainstorming.  We  simply  tried  to 
consider  all  risk  scenarios  and  tried  to  pinpoint  the  risk  involved.  We  researched 
available  literature  and  based  a  lot  of  it  on  past  personal  experience.  We  immediately 
filtered  those  risks  that  were  highly  improbable.  This  is  the  area  of  risk  assessment  that 
can  get  completely  out  of  hand.  There  is  a  seemingly  infinite  amount  of  risk  in 
everything  we  do.  There  could  be  a  lightning  strike  that  could  injure  one  of  our  team 
members  down  which  would  have  a  major  consequence  on  this  project  but  the  likelihood 
is  so  minimal  that  it  is  not  addressed.  This  philosophy  prevented  our  team  from  getting 
too  far  off  course  with  risks  that  were  not  going  to  affect  this  project. 
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To  assess  risk  we  looked  at  all  of  our  listed  risks  and  gave  eaeh  risk  a  value.  We 
used  the  following  seale  found  in  (Hall,  1998): 

•  Very  Low:  Risk  is  an  ineonvenienee  without  serious  impaet 

•  Low:  Risk  has  a  minor  impact  to  the  process  or  product 

•  Moderate:  Risk  may  disrupt  the  process  or  degrade  the  product 

•  High:  Risk  seriously  disrupts  or  degrades  a  major  part  of  the  project 

•  Very  High:  Risk  threatens  failure  of  the  project 

It  is  crucial  to  any  risk  analysis  to  stay  focused  on  the  task  at  hand  and  not  get 
ahead  of  the  management  plan.  It  is  always  tempting  to  disregard  some  risks  because  the 
mitigation  plan  is  intuitive  and  easy  to  implement.  However,  the  assessment  stage  is  not 
the  time  to  introduce  mitigation  but  rather  to  stay  focused  on  assessing  the  risk.  For 
example,  with  this  project  we  identified  the  security  of  our  site  as  a  risk.  If  someone 
broke  into  our  site  they  could  make  unauthorized  changes  and  disrupt  the  accuracy  of  the 
information  provided.  Displaying  inaccurate  information  would  make  our  site 
completely  useless.  Our  team  was  quick  to  realize  that  our  site  would  be  placed  on  the 
official  USMC  web  page  which  would  make  this  type  of  attack  unlikely.  Although  our 
site  would  not  exist  without  the  protection  of  the  USMC  server,  this  fact  needed  to  be 
overlooked  when  assessing  this  particular  risk.  We  had  to  assume  the  worst  and  simply 
assess  the  risk  as  if  we  were  going  to  place  our  site  on  an  open  web  server.  The 
mitigation  of  placing  it  on  a  secure  server  would  come  later  and  should  not  be  considered 
here. 

To  assess  likelihood  of  occurrence  for  each  risk  we  used  the  following  scale  (Hall, 

1998): 

•  Chances  are  slight,  highly  unlikely,  almost  no  chance 

•  Little  chance,  probability  not  unlikely 

•  Improbable,  we  doubt,  better  than  even 

•  We  believe,  probably,  likely 

•  Very  good  chance,  highly  likely,  almost  certainty 

There  are  several  different  ways  to  assess  the  likelihood  of  occurrence  of  a  risk. 
The  best  and  most  substantial  involve  metrics  and  using  probability  and  statistics.  This  is 
best  achieved  on  a  project  that  already  has  a  great  deal  of  data  to  go  with  it.  There  is 
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usually  a  history  of  past  risk  assessments  that  can  be  applied  to  the  current  evaluation.  In 
our  case  here  we  did  not  have  such  historical  data  to  fall  back  on  so  we  had  to  use  our 
best  estimation  based  on  our  own  experiences. 

The  risk  mitigation  for  our  project  came  much  the  same  way  the  risk 
identification  came  about.  Our  team  simply  brainstormed  and  developed  what  we  felt 
would  be  possible  mitigations  for  the  risks  we  identified.  Assuming  the  mitigation  plan 
was  implemented,  we  used  the  same  scale  as  before  to  again  determine  the  final  cost  of 
each  risk.  The  mitigation  will  only  have  an  effect  on  the  likelihood  and  not  the 
assessment.  This  is  an  important  point  to  keep  in  mind.  Identified  risk  that  truly  exists 
will  always  be  risks  to  a  project.  The  mitigation  will  only  decrease  their  likelihood  of 
occurrence  but  it  will  not  diminish  the  risk.  For  example,  if  the  risk  of  information 
security  is  identified  and  assessed  to  have  a  score  of  5  on  the  assessment  scale  above. 
That  means  that  we  feel  that  a  breach  in  the  security  of  this  system  will  have  a  very  high 
risk  and  threatens  failure  of  the  project.  We  may  believe  that  the  likelihood  deserves  a  4 
on  our  scale  which  means  it  is  likely  to  occur  if  we  do  nothing  to  mitigate  its  occurrence. 
After  putting  in  some  measure  to  mitigate  this  risk  we  can  significantly  decrease  the 
likelihood  that  this  breach  in  security  can  occur  however  we  have  done  nothing  to  lower 
the  assessment  score  of  a  5  on  our  scale.  The  risk  of  a  breach  in  security  remains  high 
but  we  have  just  reduced  the  possibility  of  occurrence  down  to  an  acceptable  level.  This 
is  the  goal  or  our  risk  management  plan. 

After  implementing  our  mitigation  plan,  we  determine  a  final  risk  cost  for  the 
identified  risk.  This  cost  is  the  final  probability  that  the  risk  will  still  occur.  It  is  our  goal 
to  reduce  all  risk  down  to  an  acceptable  level.  The  idea  of  an  acceptable  level  is 
somewhat  objective  since  risk  acceptance  can  be  so  varied  based  on  personal  beliefs  and 
the  project’s  mission.  The  fact  still  remains  that  some  risk  will  always  remain  and  not  all 
risks  can  be  reduced  down  into  an  acceptable  range.  In  these  cases  a  decision  needs  to  be 
made.  The  project  plan  can  be  adjusted  based  on  the  potential  risk  or  the  level  of  risk  can 
be  simply  accepted.  This  decision  rests  with  the  project  manager  or  the  client  but  some 
level  of  risk  will  always  exist. 
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2,  Risk  Analysis  for  Our  Thesis 

Our  team  gathered  and  did  some  brainstorming  and  identified  several  risks.  We 
immediately  disearded  some  of  our  identified  risks  based  on  the  extremely  low  likelihood 
of  oecurrenee.  We  settled  on  the  following  risks: 

1 .  Finishing  on  time  -  we  planned  to  finish  this  website  by  July  2006.  There 
was  a  risk  that  we  eould  get  behind  schedule  and  not  complete  this  project 
on  time. 

2.  Staying  within  budget  -  our  thesis  advisor  gave  us  an  allotted  amount  of 
funds  that  can  be  spent  on  a  thesis.  We  will  require  TAD  funds  for  some 
traveling  to  Quantico,  VA.  There  is  a  risk  that  we  could  go  over  our 
budget. 

3.  Information  Accuracy  -  the  Marine  Corps  Uniform  Regulations  are 
constantly  changing.  This  site  needs  to  be  updated  as  changes  to  the 
Uniform  Regulations  are  approved  and  passed  on  to  the  fleet.  We  run  the 
risk  of  having  inaccurate  information  on  our  web-site  if  it  is  not  updated 
appropriately. 

4.  Security  of  Site  -  the  threat  of  hackers  is  always  present  when  dealing 
with  the  internet.  We  have  a  risk  of  susceptibility  to  hacker  attacks.  If 
any  user  can  break  through  and  change  any  of  the  information  on  our 
website,  it  will  sacrifice  the  integrity  of  the  information  posted.  The 
information  on  this  site  needs  to  be  in  complete  compliance  with  the 
Official  Uniform  Regulations  Manual.  Any  deviations  from  this  standard 
render  this  site  useless. 

5.  Usability/ Acceptance  -  We  feel  our  biggest  risk  is  that  our  intended 
audience,  the  Marines,  will  not  use  our  website.  If  the  information  is  not 
presented  in  a  user  intuitive  and  aesthetically  pleasing  manner,  it  will  not 
be  used. 

We  gave  our  risks  the  following  assessment  values: 

1.  Finishing  on  time:  3  Moderate:  Risk  may  disrupt  the  process  or  degrade 
the  product 

2.  Staying  within  budget:  2  Low:  Risk  has  a  minor  impact  to  the  process  or 
product 

3.  Information  Accuracy :  4  High:  Risk  seriously  disrupts  or  degrades  a 
major  part  of  the  project 

4.  Security  of  Site:  4  High:  Risk  seriously  disrupts  or  degrades  a  major  part 
of  the  project 

5.  Usability/Acceptance:  5  Very  High:  Risk  threatens  failure  of  the  project 
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We  gave  our  risks  the  following  likelihood  value: 

1 .  Finishing  on  time:  3  Improbable,  we  doubt,  better  than  even 

2.  Staying  within  budget:  3  Improbable,  we  doubt,  better  than  even 

3.  Information  Accuraey:  5  Very  good  chance,  highly  likely,  almost  certainty 

4.  Security  of  Site:  5  Very  good  chance,  highly  likely,  almost  certainty 

5.  Usability/ Acceptance:  4  We  believe,  probably,  likely 
Our  risk  mitigation  plan  is  as  follows: 

1 .  Develop  a  detailed  timeline  and  stay  on  track.  Timeline  should  be  realistic 
enough  to  be  managed  but  not  have  unnecessary  delays. 

2.  We  need  to  forecast  all  TAD  costs.  There  is  no  cost  to  develop  the  site  or 
use  the  server  but  there  is  cost  for  travel  to  Quantico  VA. 

3.  We  will  pass  this  project  off  to  the  Marine  Corps  once  we  are  done.  It  will 
be  incumbent  on  them  to  keep  the  site  up  to  date  with  the  latest  changes. 
We  will  need  to  ensure  that  the  site’s  administrator  is  trained  on  this  site. 
If  this  site  is  accepted  as  an  official  USMC  website,  it  will  be  kept  up  to 
date  since  Marines  will  be  using  it  as  an  official  reference. 

4.  If  we  first  assume  that  this  site  is  placed  on  an  open  server,  we  feel  it  is 
highly  likely  that  someone  will  try  and  succeed  at  breaking  into  the  site 
and  make  malicious  changes.  Since  we  are  going  to  put  it  in  the  USMC 
web  server,  we  are  certain  of  its  security.  This  will  provide  the  protection 
we  need  to  prevent  unauthorized  changes. 

5.  We  need  to  follow  good  HCI  design  and  methods  as  illustrated  in  our  HCI 
checklist.  The  principles  of  Human  Computer  Interaction  will  be  fully 
explored  with  this  thesis.  The  design  will  be  lAW  the  principles  of  HCI 
and  will  support  quick  links  and  menu  driven  systems  that  will  allow  all 
relevant  information  to  be  displayed  or  hidden  as  the  user  requires. 

After  the  implementing  our  mitigation  plan  we  feel  that  that  we  have  substantially 
reduced  our  risks  and  we  continued  our  development  with  a  much  clearer  direction 
avoiding  some  of  the  pitfalls  that  could  have  hindered  the  process. 

C.  CONFIGURATION  MANAGEMENT 

According  to  Wikipedia,  Configuration  Management  is  defined  as  “The  control  of 
changes— including  the  recording  thereof— that  are  made  to  the  hardware,  software, 
firmware,  and  documentation  throughout  the  system  life  cycle.”  Configuration 
Management  is  the  key  to  managing  and  controlling  the  highly  complex  software  projects 
being  developed  today.  Configuration  Management  tools  have  developed  from  simple 

version-control  systems  targeted  at  individual  developers  into  systems  capable  of 
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managing  developments  by  large  teams  operating  at  multiple  sites  around  the  world.  In 
an  uncontrolled  site  where  multiple  authors  have  access  to  edit  and  contribute,  the 
potential  for  conflict  and  problems  arise.  One  author  may  spend  an  entire  day  working 
on  a  particular  file  in  the  project  and  he  may  think  that  his  changes  are  final.  However, 
after  these  changes  are  made,  another  developer  who  works  at  home  after  hours,  or  in 
another  office,  may  spend  the  night  uploading  their  own  newly  revised  version  of  the 
same  file,  completely  overwriting  the  work  of  the  previous  author  with  no  way  to  get  it 
back.  This  is  disastrous  for  project  development  and  could  be  avoided  with  proper,  and 
simple,  configuration  management  tools.  (Haas,  2002) 

For  this  project,  we  developed  our  own  tool  for  Configuration  Management. 
Although  our  team  was  co-located  during  the  development  of  this  site,  we  did  most  of  the 
work  on  the  site  at  different  locations,  our  homes.  We  may  have  been  able  to  develop 
this  site  without  developing  this  tool  but  for  the  purposes  of  this  academic  work,  we  felt  it 
necessary  to  become  familiar  with  Configuration  Management  and  implement  it  in  the 
development  of  this  site.  In  keeping  with  the  spirit  of  this  project  and  our  goal  to  become 
familiar  with  the  software  development  process,  we  realized  that  Configuration 
Management  is  a  crucial  part  of  developing  software  so  this  type  of  experience  would 
greatly  benefit  us  as  future  software  developers. 

For  our  project  we  created  our  own  Configuration  Management  tool  that  allowed 
us  to  individually  work  on  the  thesis  but  still  provide  version  control  and  instant  updates. 
We  created  a  web  based  tool  that  is  shown  in  Figure  9.  Shown  in  Figure  9  is  the  main 
page  of  the  Configuration  Management  site  which  we  used  throughout  this  project.  In 
the  center  of  the  page  we  included  a  text  area  that  details  our  timeline  and  any  notes  that 
we  felt  were  necessary.  Both  team  members  had  access  to  upload  files  and  messages  to 
the  site  which  allowed  us  to  communicate  with  each  other  while  maintaining  remote 
locations.  This  proved  to  be  invaluable  in  the  development  of  this  project.  On  the  left 
side  of  the  page,  we  linked  all  versions  of  current  documents  that  were  required.  We 
were  able  to  assign  tasks  for  any  document  to  individual  team  members  and  that  member 
would  then  upload  the  document  to  this  site  for  other  members  to  view.  This  was  the 
strategy  for  using  this  tool  and  it  follows  the  practices  of  Configuration  Management  as 


32 


described  above.  This  also  made  it  convenient  for  our  advisors  to  view  our  progress  and 
keep  up  with  the  latest  versions  of  our  documents  and  our  uniform  manual  web  site  due 
to  the  tool  being  based  on  the  web. 


We  also  used  the  left  side  of  the  page  to  hold  our  documentation  for  the  thesis 
write  up.  As  we  individually  worked  on  chapters  we  could  then  upload  them  to  the 
Configuration  Management  site  and  have  them  viewed  and  edited.  The  right  side  of  the 
page  was  reserved  for  any  links  that  we  felt  were  related  to  our  work. 


Although  the  Configuration  Management  tool  that  we  created  for  this  project  was 
quite  simple,  it  did  emphasize  the  importance  of  its  use.  We  may  have  been  able  to 
develop  this  project  without  the  use  of  such  a  tool  since  the  team  members  were  all 
centrally  located  here  at  NFS,  but  for  our  purposes  in  the  academic  environment  the  tool 
was  invaluable.  It  provided  us  the  convenience  to  work  independently  but  at  that  same 
time  it  allowed  us  the  assurance  that  our  work  was  not  being  duplicated  and  would  be 
seen  by  other  team  members. 
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Figure  9.  Configuration  Management  Website 


OacMmant  dooaload 
loMar 

• 

• 

-  drwiBw 

•r  UAaufiadQ 

• 

tW«H '  PrMMi  1 « 1  •«* 
i*m.  I4(pal) 

• 

wntfortn  r*g«4«tlo« 

• 

oUCir  pretMt  Mm 

• 

K<»k  An«VM» 

• 

SMvntv  A»»>ir*H 

• 

UM  la) 

• 

mt  Cam*  (ward 
dKwnMl) 

• 

Uat  <«»««  d4*ar«rw« 
()«•  19) 

• 

KAO 

• 

KAO  (ward  daiaMnartt} 

• 

S09  (ward  dacawwl) 

• 

aldHruSara)ac« 

((Vatatyw  |.0) 

• 

Pratatypa  7.0a  (ta«ia) 

• 

PratatTpa  7.1 

• 

Pratatvaa  1.0 

• 

1  laal 

. 

Chapter  1 

. 

Chapler  2 

• 

ClMmler3 

. 

Chapter  4 

• 

Chapter  5 

• 

AppeiMlix 

Mm,  ptforma(»om 
dndrMourcM  art 
avadabk  M  POf . 
TXT  or  JPG  Mm. 

DownloadabI* 
•oftwara  *% 
frMwtrt  and 
contavM  the 
nacMsarv  kenaea. 

•  Adntk)  peoc 

(rcstrkted) 


EXTEPNAl  LINKS: 


Pffkifll) 
RiMmi 
(lic£ker 
USB  mini 
sccvcr 

(AlMChc 
HfIP. 
HySOU 
PHP.  Peril 


33 


D,  EVOLUTION  AND  REUSE 

This  system  has  been  designed  in  order  to  allow  for  easy  maintenanee.  The 
designers  of  this  system  will  not  be  responsible  for  any  future  maintenanee  of  this  system 
so  it  was  our  intention  to  build  this  site  and  turn  all  files  over  to  Headquarters  Marine 
Corps  for  implementation.  Our  design  goal  was  to  allow  this  site  to  be  usable  for  many 
years  to  eome  within  the  Marie  Corps.  This  ean  only  be  aehieved  if  the  site  is  easily 
maintainable  and  files  ean  be  edited  or  deleted  as  the  MCO  ehanges.  In  order  to  aehieve 
the  desired  maintainability,  the  design  must  adhere  to  the  following; 

1,  Reliability 

The  reliability  of  this  system  will  be  dependent  on  the  stability  of  the  code  and  the 
capacity  for  system  upgrades.  The  design  of  this  system  has  been  done  with  the  goal  of 
system  reliability  in  mind. 

2,  Efficiency 

This  system  must  be  designed  to  maximize  the  efficiency  of  the  code.  This  has 
been  done  by  inhibiting  overloading  and  preventing  unnecessary  parts  of  the  code.  All 
written  code  has  been  thoroughly  scrubbed  for  gratuitous  code  or  fdes. 

3,  Understandability 

This  will  be  a  key  aspect  to  maintaining  this  site.  The  documentation  provided  in 
the  System  Design  Specification  as  well  as  the  structure  of  the  files  will  help  future 
maintainers  to  understand  the  site  and  assist  in  implementing  any  changes.  It  is  unknown 
as  to  the  technical  expertise  and  experience  of  the  future  maintainer  of  this  site  so  full 
documentation  is  critical. 

4,  Measurability 

Software  metrics  can  be  used  to  estimate  the  project  budget  and  schedule, 
evaluate  individual  productivity  and  quality,  evaluate  project  productivity  and  quality, 
and  evaluate  the  system  quality. 

The  design  specifications  for  this  system  call  for  the  design  of  a  web  based 
uniform  manual  for  the  United  States  Marine  Corps.  However,  the  same  need  can  be 
paralleled  to  any  service  within  the  Department  of  Defense  or  any  international  military 
organization.  This  system  has  been  designed  with  the  concept  of  reuse  in  mind.  The 
system  developed  here  can  be  easily  transferred  into  any  other  service  branch  with  a  file 
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structure  that  is  generic  enough  to  allow  for  the  input  of  any  uniform  type  and  a  system 
structure  that  can  support  any  similar  specification. 

E.  HUMAN  COMPUTER  INTERACTION 

To  facilitate  an  efficient  system  use  and  to  guarantee  user  acceptance  we  needed  a 
tool,  a  guideline,  based  on  HCI  principles.  This  guideline  became  a  set  of  eleven 
categories  for  the  visual  and  usability  design.  After  reviewing  several  references,  we 
developed  the  following  categories  that  we  feel  are  essential  to  successful  web  design; 

1,  Category  1:  Simplicity 

Simplicity  provides  the  means  by  which  the  web  page  aims  to  keep  the  basic 
utility  of  the  interface  easy  to  use,  and  offer  facilities  which  are  of  a  clear  value  to  the 
military  member.  The  interface  should  be  intuitive  and  there  should  be  no  question  as  to 
how  to  use  this  manual.  We  designed  our  site  by  mirroring  the  official  USMC  web  page 
found  at  www.USMC.mil.  The  basic  outline  of  this  site  is  one  that  is  well  recognized  by 
all  Marines  and  it  provided  us  with  a  simple  template  to  follow. 

2,  Category  2:  Consistency 

The  user  should  feel  that  he  or  she  is  in  control  and  that  the  system  is  responding 
to  his  or  her  actions  accordingly.  Users  should  have  control  over  the  amount  of 
information  they  receive  at  different  points  of  the  interaction.  During  the  interaction,  the 
web  page  should  have  a  common  look  and  presentation  that  is  presentable  and 
professional.  As  explained,  the  manual  is  broken  up  into  four  main  categories;  male 
officer,  male  enlisted,  female  officer,  female  enlisted.  During  exploration  of  this  manual, 
each  category  is  easily  identified  and  allows  for  ease  of  presence  within  this  site. 

3,  Category  3:  Control 

Control  actions  initiated  by  the  user  should  receive  the  appropriate  responses. 
Error  and  control  messages  should  generate  the  same  responses  throughout  this  site.  We 
allowed  for  the  user  to  maintain  complete  control  of  the  navigation  and  access  of  this  site. 
We  ensure  that  every  link  remains  active  and  all  areas  of  the  site  are  easily  navigable. 

4,  Category  4:  Shortcuts  and  Customization 

The  web  page  should  present  mechanisms  for  users  to  customize  settings  to  speed 
frequency  of  use  by  users.  We  accomplish  this  by  allowing  the  main  navigation  bars  to 
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be  constantly  visible  and  accessible  by  the  user.  This  allows  the  user  to  determine  his 
own  outcome  and  retrieve  his  own  desired  information. 

5,  Category  5:  Screen  Layout 

The  screen  layout  should  give  an  appearance  of  clarity  with  the  proper  use  of 
white  space  to  separate  items.  Items  should  be  presented  in  a  balanced  fashion,  and  not 
distort  during  screen  resolution  change.  This  shall  be  achieved  by  the  use  of  a  “liquid 
design”.  This  “liquid  design”  guarantees  that  most  or  all  functions  and  information  are 
visible  on  all  common  PC  monitor  types  and  sizes.  Additionally,  control  maneuvers 
should  be  reachable  without  scrolling  extensively. 

6,  Category  6:  Feedback 

Appropriate  feedback  before,  during,  and  after  interaction  is  essential  to  proper 
HCI.  Prompts  and  directions  should  be  provided  to  the  user  at  all  times.  The  user  should 
never  be  left  in  a  state  of  question. 

7,  Category  7:  Error  Handling 

There  shall  be  no  means  of  deleting  or  changing  information.  This  action  will 
allow  the  user  freedom  of  experimentation  without  degradation  of  the  information 
presented  on  this  site.  This  will  ensure  error  handling  is  at  a  minimum  in  regards  to 
development  of  this  site. 

8,  Category  8:  Efficiency 

All  accessible  elements  of  the  web  page  are  generated  in  a  timely  manner.  To 
ensure  an  independence  from  the  client  device  (and  thereby  allowing  every  web  enabled 
client  device  to  use  this  manual)  all  necessary  data  processing  and  code  generation  will 
be  done  by  the  server  side.  The  information  provided  within  this  site  is  in  conjunction 
with  the  latest  regulation  regarding  the  specific  uniform  in  question.  In  an  effort  to  speed 
efficiency,  a  “SEARCH”  feature  should  also  be  implemented.  The  added  feature  will 
allow  expert  users  extended  usability  of  this  manual. 

9,  Category  9:  Help  Facilities 

The  web  page  will  provide  a  mechanism  to  report  problems  or  errors.  Additional 
help  facilities  regarding  military  uniform  regulations  will  also  be  provided.  The  current 
version  of  our  site  does  not  include  a  “help”  function  but  it  could  be  implemented  if 
required  by  the  Marine  Corps. 
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10,  Category  10:  Navigation 

Navigation  within  the  web  presenee  should  be  easily  aehieved  with  minimal 
“clieks”  or  drop  down  menus  to  aehieve  a  desired  result.  We  feel  that  this  is  elearly 
demonstrated  in  our  site.  We  foeused  intently  on  providing  the  required  information  in 
the  most  expeditious  manner.  The  written  uniform  regulation  manual  eontains  an 
enormous  amount  of  information  that  is  extremely  difficult  to  comprehend.  One  of  our 
primary  goals  was  to  allow  easy  navigation  and  we  feel  like  we  accomplished  this  with 
this  site. 

11.  Category  11:  Objects 

Each  major  category  will  have  similar  index  pages  and  file  structures.  The 
objects  that  will  be  created  from  the  index  page  as  the  user  completes  a  search  for  desired 
information  are  shown  in  Figure  10.  Generic  layouts  for  other  pages  are  shown  in 
Figures  11  and  12.  These  are  not  objects  as  normally  recognized  in  object  oriented 
programming,  but  we  refer  to  them  as  objects  for  explanatory  purposes.  Since  this  entire 
system  is  web  based,  objects  are  not  truly  created  but  rather  each  selection  calls  a  desired 
page  within  the  web  server. 
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IV.  FORMAL  TESTING 


A.  INTRODUCTION 

Our  most  valuable  learning  point  throughout  our  entire  thesis  work  is  the 
importanee  of  testing  when  developing  software.  The  striet  Unified  Proeess  that  we 
mirrored  in  this  web  site  development  ealls  for  a  formal  testing  phase  eonsistent  with  the 
iterative  proeess.  We  realized  early  on  the  value  of  proper  and  in-depth  testing  in  the 
overall  sueeess  of  our  system.  We  did  not  want  to  fall  into  the  trap  of  not  leaving  enough 
time  for  solid  testing  and  we  did  not  want  to  leave  testing  as  an  after- thought.  We  built 
into  our  timeline  for  the  development  of  this  system  plenty  of  room  for  a  thorough  testing 
phase  to  inelude  the  time  needed  to  implement  the  ehanges  learned  from  our  testing  and 
then  re-testing  the  site  with  those  changes.  What  we  did  not  fully  realize  was  that  testing 
of  a  system  is  not  just  limited  to  the  formal  testing  phase. 

Throughout  the  development  process  of  this  system,  we  have  been  conducting 
“informal”  testing.  There  are  many  levels  of  testing  that  a  system  goes  through  while  it  is 
being  developed.  During  the  inception  phase,  we  tested  the  soundness  of  the  general  idea 
and  scheme  that  we  envisioned  for  this  system.  Figure  13  shows  our  original  flow  chart 
from  our  Requirements  Document  that  shows  the  flow  of  information  as  we  planned  in 
the  inception  phase.  We  devoted  a  lot  of  time  in  developing  this  flow  chart  because  we 
knew  that  it  would  be  the  foundation  to  the  entire  development  process.  We  conducted 
our  own  test  and  evaluation  of  our  flow  chart  just  amongst  our  development  team  which 
proved  to  be  invaluable  to  allowing  us  to  fully  understand  our  plan  for  information  flow 
and  it  clarified  our  vision  of  the  entire  layout  of  our  system. 
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Figure  13.  Flowchart 


We  used  several  tools  for  this  type  of  “informal”  testing  including  flow  charts  and 
prototypes  but  we  also  relied  on  basic  trial  and  error  as  we  designed  the  site.  We 
constantly  had  a  local  server  running  on  the  computer  we  used  to  program  the  design  and 
we  simply  would  view  pages  as  we  created  or  changed  them  for  instant  feedback.  This 
type  of  on-demand  testing  along  with  other  informal  testing  methods  proved  extremely 
important  in  the  overall  development.  We  set  our  own  standard  for  this  system  and  we 
did  not  move  forward  until  we  were  satisfied  with  the  design  at  that  point.  As  we  moved 
into  the  formal  testing  phase,  we  were  much  more  confident  that  our  system  would  test 
well  with  our  subjects  because  it  had  already  passed  our  own  testing  standards.  This 
“informal”  testing  was  much  more  ad-hoc  and  specified  as  compared  to  the  formal  testing 
but  it  saved  us  a  tremendous  amount  of  time  in  the  overall  process. 
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For  our  formal  testing  phase  we  used  a  usability  lab  provided  by  Dr.  Ciavarelli. 
The  lab  eonsisted  of  two  lap  top  eomputers,  three  eameras,  and  a  voiee  recorder.  The  test 
computer  was  used  by  our  subjects  and  we  used  the  observation  computer  to  monitor  and 
run  the  tests.  The  test  computer  was  loaded  with  a  local  server  which  housed  our  entire 
site.  One  camera  was  placed  at  eye  level  to  record  the  test  subject’s  eye  movement  while 
looking  at  our  site.  The  second  camera  was  positioned  to  record  the  subject’s  hands  on 
the  keyboard  to  record  keystrokes  and  mouse  movement.  The  third  camera  was  set  to 
capture  the  profile  view  of  the  subject  in  order  to  capture  head  movement.  We  used  the 
voice  recorder  to  allow  the  subject  to  orally  detail  their  thoughts  and  critiques  and  to 
allow  instant  feedback.  We  felt  this  was  much  more  effective  than  having  the  subject  go 
through  the  site  and  then  write  down  their  comments  afterward.  Getting  the  instant  voice 
recording  prevents  the  problem  of  subjects  having  to  recall  their  thoughts  after  the  test  is 
completed  and  avoids  the  nuisance  of  having  to  write  down  the  information.  Oral 
feedback  allows  the  subjects  to  speak  freely  and  openly  and  they  are  more  likely  to 
provide  detailed  comments  than  if  they  had  to  write  their  thoughts  down.  We  did  have 
the  subjects  complete  a  survey  as  found  in  Appendix  IV  but  this  was  a  short  concise 
survey  that  was  simply  used  to  consolidate  the  test  results  from  each  subject.  The  voice 
recordings  were  used  to  provide  detailed  information  that  we  could  go  back  to  and  make 
the  changes  as  suggested. 

B,  TEST  1 

Our  first  test  was  conducted  with  five  subjects  all  of  which  were  male  Marine 
officers  currently  enrolled  in  the  Computer  Science  curriculum  at  the  Naval  Postgraduate 
School.  These  subjects  had  between  10  to  17  years  of  experience  in  the  Marine  Corps 
and  all  possessed  high  levels  of  technical  skills.  They  were  all  very  familiar  with  the 
current  Marine  Corps  Uniform  Manual  and  they  were  all  familiar  with  our  project 
through  informal  conversations  with  our  team  while  we  were  developing  this  system.  All 
of  the  subjects  were  hand  selected  by  our  team  because  of  these  qualifications.  We  knew 
this  was  a  specialized  group  for  testing  and  they  would  provide  uniquely  tailored 
responses  and  feedback.  Since  this  was  our  first  attempt  at  testing  this  system  in  a  formal 
setting,  we  wanted  to  have  a  controlled  environment  with  a  group  of  selected  subjects 
that  had  a  high  level  of  familiarity  in  order  to  validate  our  own  evaluation  of  this  site. 
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Our  team  felt  that  the  site  was  well  formed  and  very  close  to  a  final  product  before  we 
began  testing  but  we  needed  to  corroborate  this  with  our  subjects. 

The  usability  lab  was  set  up  as  described  above  with  two  computers,  three 
cameras,  and  a  voice  recorder.  The  subjects  were  asked  to  follow  a  written  scenario 
(Appendix  IV)  provided  by  our  team.  The  scenario  was  intended  to  provide  a  common 
baseline  in  order  for  a  sound  comparison  to  be  done  on  all  five  subjects.  The  questions 
on  this  scenario  asked  the  subjects  to  find  various  uniform  requirements  and  we 
attempted  to  derive  questions  that  users  may  ask  of  this  system.  The  actual  answers  to 
these  questions  were  not  as  important  as  simply  giving  the  subjects  some  direction  so 
they  would  have  to  navigate  through  a  large  portion  of  the  site.  We  felt  that  if  we  just 
had  our  subjects  browse  our  site  as  they  wished,  they  may  not  thoroughly  navigate  the 
site  and  they  would  not  be  able  to  provide  us  useful  feedback.  All  five  subjects  gave  us 
instant  oral  feedback  and  they  all  completed  our  survey  for  a  written  record  of  the  test. 
These  completed  surveys  are  provided  in  Appendix  IV. 

This  first  round  of  formal  testing  proved  to  be  quite  successful.  We  learned  that, 
overall,  our  web  site  was  progressing  as  our  team  had  assessed.  The  HCI  design 
principles  described  in  Chapter  3  of  this  document  that  we  attempted  to  follow  showed  an 
initial  successful  implementation.  The  subjects  gave  us  positive  feed  back  on  the  overall 
navigation  of  the  site  and  the  layout  of  the  pages  to  include  color  and  font.  We  designed 
our  site  to  be  consistent  in  structure  and  aesthetics  with  other  Marine  Corps  sites  that  are 
currently  available  on  the  web.  Some  of  the  subjects  immediately  commented  on  that 
fact  and  stated  that  they  felt  like  they  recognized  the  layout  and  instantly  felt  comfortable 
with  the  structure.  All  of  the  subjects  suggested  that  we  implement  a  “search”  function  to 
allow  a  user  to  more  quickly  find  desired  information.  We  agreed  with  this  assessment 
but  we  will  leave  the  implementation  to  the  Marine  Corps.  We  received  several  other 
suggestions  for  some  minor  changes  that  we  were  able  to  quickly  implement  due  to  the 
simple  file  structure  that  was  used  when  designing  this  site. 

A  very  important  point  that  we  learned  during  this  initial  phase  of  testing  was  that 
we  were  able  to  test  our  testing  procedures  themselves.  In  this  instance,  both  of  our  team 
members  sat  side  by  side  with  the  subjects  as  they  were  testing  the  site.  This  made  it 
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very  tempting  for  our  team  to  steer  the  subjeets  around  the  site  and  offer  suggestions 
while  navigating.  We  also  found  ourselves  explaining  away  some  of  the  eritiques  being 
offered  by  the  subjects.  Of  course,  this  type  of  input  skews  the  results  of  the  testing  and 
makes  it  difficult  for  subjects  to  objectively  evaluate  the  site.  The  usability  lab  has  the 
capability  to  conduct  remote  testing  with  the  observer  computer  placed  in  a  separate 
location  from  the  subject.  We  will  implement  this  in  our  next  phase  of  testing  to  avoid 
the  temptation  of  helping  the  subjects  with  using  the  site.  The  subjects  did  find  that  the 
scenario  driven  questions  did  prove  to  be  very  useful  in  keeping  them  moving  within  the 
site.  This  was  only  successful  by  having  the  subjects  speak  aloud  while  they  were 
attempting  to  answer  the  questions  provided  and  they  felt  free  to  make  any  comments 
while  searching.  The  running  dialogue  proved  to  be  the  most  useful  information 
provided  during  testing.  The  subjects  were  encouraged  to  speak  freely,  regardless  of  how 
minor  there  critiques  seemed.  Some  suggestions  were  beyond  the  scope  of  this  project 
but  most  were  implemented. 

C.  TEST  2 

For  the  second  round  of  our  testing  we  focused  on  testing  female  Marine  officers. 
After  receiving  the  feedback  from  the  male  Marine  officers  during  the  first  test,  we  felt 
that  we  could  build  the  entire  site  and  complete  all  of  the  navigation  for  “Male  Enlisted”, 
“Female  Officer”,  and  “Female  Enlisted”.  We  felt  that  the  male  officer  subjects  used  in 
the  first  round  of  testing  gave  us  an  adequate  representation  of  that  gender  and  rank  so  we 
decided  that  we  needed  to  target  other  audiences.  The  female  subjects  used  for  testing 
were  all  female  captains  but  ranged  in  experience  from  10  years  to  15  years.  Given  our 
current  location  here  at  NFS,  we  are  limited  to  the  number  of  female  officers  from  which 
to  choose  but  we  felt  it  crucial  to  have  the  site  evaluated  from  a  female  officer 
perspective. 

Since  the  site  was  working  in  its  entirety  for  this  portion  of  the  testing,  we  needed 
to  adjust  the  scenario  provided  to  the  subjects  for  testing.  The  scenario  is  provided  in 
Appendix  IV.  This  scenario  now  required  the  subjects  to  navigate  the  entire  site  to 
include  switching  between  different  ranks  and  genders.  The  challenge  here  is  that  since 
the  site  is  now  four  times  as  big  as  it  was  during  the  first  round  of  testing,  it  is  very 
difficult  to  have  the  subjects  visit  a  large  portion  of  the  site.  We  found  that  it  was  crucial 
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to  keep  the  testing  scenarios  short  in  order  to  keep  the  interest  level  of  the  subjects  high 
and  provide  valuable  feedback.  If  the  testing  lasts  too  long,  the  subjects  tend  to  lose 
interest  and  they  feel  that  the  testing  has  now  become  a  burden.  This  would  negatively 
affect  the  feedback  provided  by  the  subjects  and  would  degrade  the  value  of  the  testing. 
Our  challenge  then  becomes  to  design  a  scenario  that  requires  the  subjects  to  navigate 
through  as  much  of  the  site  as  possible  but  complete  the  testing  in  a  limited  time.  The 
scenario  in  Appendix  IV  was  completed  in  only  20  minutes  by  the  subjects  but  it  does 
drive  the  users  to  each  rank  and  gender  of  the  site. 

D,  TEST  3 

For  our  next  round  of  testing  we  focused  on  enlisted  Marines  of  both  female  and 
male  gender.  At  this  point  we  had  tested  the  site  on  both  males  and  females  and  we  were 
able  to  make  adjustments  to  the  site  as  necessary.  We  were  confident  in  the  navigation  of 
the  entire  site  and  we  made  adjustments  to  maximize  the  functionality.  Our  previous  test 
cases  hardened  our  resolve  in  the  usability  of  the  site  but  we  still  felt  that  we  needed  to 
test  for  the  accuracy  of  the  information  provided  within  the  site.  Thus  far  we  used  strictly 
Marine  officers  so  we  shifted  our  test  subjects  to  enlisted  Marines.  This  proved  to  be  the 
most  valuable  round  of  testing  completed. 

All  of  the  test  subjects  were  found  at  the  Defense  Language  Institute  at  the 
Presidio  of  Monterey.  They  were  all  enlisted  Marines,  both  male  and  female,  ranging  in 
rank  from  Private  First  Class  to  Corporal.  Their  years  experience  ranged  from  4  months 
to  4  years.  The  most  surprising  detail  of  their  background  was  that  they  had  a  wide  range 
of  technical  experience.  This  was  unlike  the  Marine  officer  subjects  of  the  previous 
rounds  of  testing  who  were  all  Master’s  degree  students  and  all  possessed  a  high  level  of 
technical  skill  and  computer  savvy.  The  enlisted  subjects  ranged  from  web  designers  to 
complete  computer  novices  with  very  little  web  surfing  experience.  We  were  extremely 
surprised  to  find  such  a  high  level  of  computer  experience  with  some  of  the  subjects 
conversing  at  the  technical  level  as  to  the  file  structure  and  design  of  the  site.  However, 
we  were  equally  surprised  to  discover  that  some  of  the  subjects  clearly  had  a  fear  of  using 
computers  and  were  complete  novices  to  surfing  the  web  and  looking  at  web  sites.  We 
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became  quickly  convinced  that  the  audience  of  potential  users  of  this  site  is  much  more 
diverse  than  originally  estimated  and  this  round  of  testing  would  truly  stretch  the  limits  of 
the  structure  and  design  of  the  site. 

After  the  first  few  subjects  completed  their  testing,  we  found  it  necessary  to  adjust 
the  scenario  driven  testing.  The  scenarios  provided  in  Appendix  IV  proved  successful  in 
the  first  two  rounds  of  testing  but  were  actually  limiting  the  subjects  during  this  third 
round  of  testing.  What  we  found  is  that  the  enlisted  Marines  were  too  focused  on  the 
answers  to  the  questions  provided  and  were  not  providing  enough  feedback  on  the  site 
itself  It  seems  that  the  enlisted  Marines  are  so  driven  to  complete  any  task  given  that 
they  become  blindly  focused  on  completing  that  task.  We  tried  to  emphasize,  as  we  did 
the  male  and  female  officers  that  the  scenario  is  only  provided  to  allow  them  some 
guidance  to  navigating  the  entire  site  but  that  it  was  not  intended  to  be  a  test  of  their 
knowledge  of  the  uniform  manual.  For  example,  the  question  “What  is  the  hem  size  on  a 
male  enlisted  Service  Dress  C?”  was  only  provided  to  require  the  subjects  to  navigate 
within  the  male  enlisted  sub-site.  The  answer  to  the  question  was  not  at  all  important,  we 
just  wanted  to  provide  the  subjects  some  guidance  to  ensure  that  they  were  not  just 
aimlessly  browsing  the  site.  The  enlisted  Marines  became  narrowly  focused  on 
answering  the  questions  provided  and  lost  sight  of  our  true  intentions  and  the  reasoning 
behind  the  scenario  driven  testing. 

Our  solution  to  this  problem  was  to  have  the  subjects  create  5  questions  of  their 
own  regarding  the  USMC  uniform  regulations.  They  then  stated  their  question  out  loud 
before  proceeding  and  they  were  required  to  find  the  answer  to  their  question  using  the 
web  site.  This  actually  turned  out  to  be  extremely  beneficial  to  the  feedback  received 
since  this  was  much  more  closely  resembled  the  way  this  site  would  actually  be  used. 
We  anticipate  users  desiring  to  gain  some  information  about  their  own  uniforms  or  about 
a  particular  rank  and  gender  and  then  using  our  site  to  find  the  answers.  This  new  testing 
strategy  prevented  the  users  from  being  so  narrowly  focused  on  answering  our  questions 
and  allowed  them  to  use  the  site  in  a  realistic  way.  This  had  the  positive  effect  of 
allowing  the  users  to  provide  us  commentary  on  the  site’s  design,  functionality,  and 
accuracy  of  information,  which  is  the  purpose  of  testing. 
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The  feedback  provided  from  this  round  of  testing  proved  to  be  invaluable.  We 
were  able  to  confidently  adjust  the  site  to  be  usable  for  a  much  wider  range  of  users.  The 
site  became  structured  to  accommodate  male  Marines  as  well  as  female  Marines,  officers 
and  enlisted,  and  Marines  new  to  the  Marine  Corps  as  well  as  very  experienced  Marines. 
But  the  most  valuable  lesson  learned  from  this  round  of  testing  is  that  our  site  tested  to  be 
usable  to  the  computer  savvy  Marines  as  well  as  for  the  Marines  with  very  limited 
computer  expertise. 
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V.  CONCLUSION  AND  FUTURE  RESEARCH 


In  conclusion  we  felt  that  we  had  a  very  suecessful  thesis  project.  We  were  able 
to  aceomplish  our  goals  presented  in  Chapter  I  while  learning  mueh  more  than  we 
initially  anticipated.  Although  it  was  not  our  original  intent,  we  have  beeome  experts 
with  the  eurrent  Marine  Corps  uniform  regulations  manual.  This  is  due  to  the  fact  that 
we  were  required  to  thoroughly  evaluate  the  current  manual  in  order  to  implement  it  in  an 
easy  to  use  web  site.  We  needed  to  be  preeise  on  the  requirements  for  wearing  all 
uniforms  and  their  accessories  in  order  to  provide  the  users  with  eompletely  accurate 
information.  In  our  researeh  we  found  numerous  contradietions  and  errors  with  the 
current  manual  that  required  the  attention  of  the  official  United  States  Marine  Corps 
Uniform  Board.  They  are  responsible  for  maintaining  the  regulation  and  ensuring  its 
accuracy.  They  were  pleased  that  we  were  attempting  to  build  this  site  for  their  use  and  it 
is  with  this  board  that  our  team  will  deliver  the  final  product.  An  example  of  one  such 
discrepancy  is  there  is  currently  a  contradiction  in  the  manual  as  to  the  wearing  of  the 
male  all  weather  eoats.  In  one  section  of  the  manual  it  states  that  the  all  weather  coat 
could  be  optionally  worn  with  the  Evening  Dress  uniform.  However,  that  statement  is 
contradicted  later  in  the  manual  with  the  statement  “The  AWC  may  be  worn  or 
prescribed  for  wear  with  the  service,  dress,  and  utility  uniforms.”  There  is  no  mention  of 
the  Evening  Dress  uniform.  These  types  of  errors  were  independently  corrected  with  the 
uniform  board  for  aecuracy. 

We  eonclude  that  following  the  Unified  Proeess  for  web  development  definitely 
led  to  the  suceessful  completion  of  sueh  a  eomplex  web  site.  Eollowing  such  a  process 
allowed  us  to  focus  during  the  development  of  this  site  and  it  narrowed  our  eenter  of 
attention  to  the  tasks  that  allowed  us  to  progress  to  a  finished  product.  We  spent  a 
eonsiderable  amount  of  time  up  front  in  the  Inception  Phase  and  the  Elaboration  Phase 
whieh  paid  off  during  the  Construetion  Phase.  It  was  very  tempting  for  us  to  shorten  the 
first  two  stages  and  dive  deeply  into  eonstructing  the  site.  The  temptation  to  do  this  was 
caused  by  the  faet  that  it  is  in  the  Construetion  Phase  that  the  goal  of  ereating  the  site  is 
attained.  We  made  a  concerted  effort  to  follow  the  guidelines  of  the  process  and  used  the 

tools  provided  to  create  a  detailed  plan  with  whieh  to  follow  before  writing  any  eode. 
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Since  this  is  an  iterative  proeess,  we  did  take  advantage  of  the  flexibility  that  allowed  us 
to  fluetuate  between  phases  and  stay  within  the  bounds  of  the  framework. 

Although  we  are  convinced  that  the  Unified  Proeess  is  an  excellent  tool  to  use 
when  developing  a  eomplex  web  site,  we  are  still  uncertain  about  the  efficieney  of  using 
such  a  process.  It  is  difficult  to  say  whether  we  eould  have  developed  this  same  site  in  a 
shorter  amount  of  time  having  used  a  different  process  or  no  proeess  at  all.  There  were 
many  factors  that  drove  our  schedule  and  leave  some  doubt  as  to  the  efficieney  of  the 
process. 

One  of  our  team  members  did  have  some  prior  experience  with  web  development 
and  design  but  nothing  as  complex  as  the  site  for  this  thesis.  His  style  was  mueh  more  ad 
hoc  with  no  set  process  followed  as  most  web  designers  are  inelined  to  do.  Neither  one 
of  us  had  any  experience  with  developing  software  with  the  Unified  Proeess.  We  had 
been  exposed  to  the  process  in  theory  while  here  at  NPS,  but  we  had  no  practical 
experience.  We  found  ourselves  learning  the  proeess  while  we  were  aetually 
implementing  its  praetices.  This  fact  leads  to  our  doubt  as  to  the  time  needed  to  complete 
this  site.  Were  we  slowed  down  beeause  we  were  not  fully  eomfortable  with  using  the 
Unified  Process  or  were  we  slowed  down  because  the  Unified  Process  is  not  designed  for 
web  site  development?  We  conclude  that  the  former  is  more  accurate  rather  than  the 
latter  but  future  attempts  at  this  same  type  of  development  would  give  a  definitive 
answer. 
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APPENDIX.  WEB  BASED  UNIFORM  REGULATIONS  MANUAL 

SUPPORT  DOCUMENTS 
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I.  REQUIREMENTS  ANALYSIS  DOCUMENT  (RAD) 


A.  REVISION  SHEET 


Revision  Number 

Date 

Brief  Description  of  Changes 

B,  INTRODUCTION 

1,  Purpose 

The  purpose  of  this  Requirements  Analysis  Document  (RAD)  is  to  define  the 
requirements  for  the  Web  Based  Uniform  Regulations  Manual  and  to  present  them  to  the 
customer  for  review,  comment,  and  validation.  The  RAD  includes  a  flow  chart  of 
information  paths.  Use  Case  Diagrams,  Use  Cases,  System  Sequence  Diagrams,  a  list  of 
the  required  options  for  the  home  page  along  with  a  detailed  diagram  of  each  selection, 
and  a  decision  tree  to  visually  display  the  options  necessary  to  choose  a  uniform  display. 

2,  Background 

The  current  United  States  Marine  Corps  Uniform  Regulations,  titled  Marine 
Corps  Order  P1020.34G,  is  available  in  hard  copy  or  on-line  in  PDF  format  only.  There 
is  not  a  Graphical  User  Interface  system  currently  in  existence  for  this  information,  and  in 
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its  current  form,  traversing  this  doeument  can  be  a  tedious  proeess  and  time  consuming. 
As  with  most  military  manuals  of  its  kind,  was  not  written  in  a  user  intuitive  manner. 


Major  issues/concerns  with  existing  manual: 

•  The  current  manual  requires  multiple  pages  to  be  repeatedly  refereneed 
before  being  fully  understood. 

•  Verbiage  can  be  distraeting  and  cause  regulations  to  be  misunderstood. 

•  It  does  not  provide  a  “quick  reference”  for  user  convenience. 

•  Changes  to  regulations  require  entire  manuals  to  be  generated  and 
replaeed,  leading  to  older  versions  with  outdated  materials  still  in 
eireulation. 

•  Not  written  to  be  “user  intuitive”. 

•  Even  experienced  users  ean  have  problems  quickly  accessing  the 
information  they  require. 

3,  Scope  and  Audience 

The  web  based  manual  described  in  this  doeument  will  be  in  strict  accordance 
with  MCO  P1020.34G.  This  system  will  be  relied  on  by  Marines  world  wide  as  an 
accurate  souree  of  standards  that  ensure  their  compliance  with  the  MCO.  The  new 
design  will  be  lAW  the  principles  of  HCI  and  will  support  quiek  links  and  menu  driven 
systems  that  will  allow  all  relevant  information  to  be  displayed  or  hidden  as  the  user 
requires.  The  new  system  will  address  all  aspeets  currently  outlined  in  the  regulations, 
such  as  proper  wearing  of  the  uniform,  grooming  standards,  ribbon  and  medal 
precedenee,  civilian  attire,  PT  gear,  and  optional  items  for  male  and  female  officers  and 
enlisted  U.  S.  Marines.  This  system  could  be  used  by  all  US  civilians  and  military 
service  members  to  whom  the  eurrent  manual  is  now  relevant. 

4.  References 

•  Bruegge,  Bernd.  Object-Oriented  Software  Engineering.  Pearson  Prentice 

Hall,  Inc.  2004 

•  Larman,  Craig.  Applying  UML  and  Patterns:  an  introduction  to  object 
oriented  analysis  and  design  and  iterative  development.  Pearson 
Edueation  Inc.  2005. 

•  Hall,  Elaine  M.  Managing  Risk.  Addison  -  Wesley.  1998. 

C.  GENERAL  DESCRIPTION 

1,  Product  Perspective 
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The  overall  goal  of  the  projeet  will  be  to  create  an  easy  to  use  web  based  uniform 
regulation  guide  in  accordance  with  Marine  Corps  Order  P1020.34G. 

2,  Product  Function 

The  guide  will  be  implemented  using  primarily  visual  aides  and  follow  the 
practices  of  good  Macro/Micro  HCI  Design.  The  aim  will  be  to  provide  the  needed 
information  to  the  user  in  an  easy  to  use  GUI  interface  that  requires  minimal  “mouse 
clicks”  to  retrieve  the  desired  information.  The  guide  will  also  provide  the  user  with 
alternative  text  from  the  current  MCO  dealing  with  the  specific  uniform  in  question.  The 
end  result  will  be  an  easy  to  use  research  tool  that  may  be  utilized  by  military  members  of 
the  United  States  Marine  Corps  as  well  as  any  person  requiring  specific  uniform 
regulations. 

D,  USER  ANALYSIS 

The  challenge  of  the  project  design  lies  in  the  fact  that  the  user  population  is 
widely  varied  in  education  (civilian  and  professional),  computer  savvy,  age,  and  cultural 
background.  Interaction  with  the  GUI  interface  to  the  system  needs  to  be  intuitive  for  the 
user  with  a  high  school  background  and  minimal  computer  skills  while  simultaneously 
not  alienating  the  more  educated  user  population.  Additionally,  implementing  multimedia 
suitable  and  appealing  for  both  the  young  and  older  users  will  prove  arduous.  Finally,  in 
order  to  avoid  confusion,  we  must  be  vigilant  in  our  usage  of  terminology  (especially 
acronyms)  that  is  only  prevalent  in  certain  cultures. 

1.  User  Characteristics 

The  expected  users  of  this  system  include  all  members  of  the  U.S.  Marine  Corps 
as  well  as  any  other  military  members  desiring  information  regarding  Marine  Corps 
uniforms.  Users  may  also  include  civilians  requiring  the  same  information. 

2,  User  Experience 

The  expected  users  will  range  from  Marines  with  very  little  military  experience  to 
career  Marines  whom  have  dedicated  a  lifetime  to  the  Marine  Corps  and  are  well  versed 
in  the  current  uniform  regulations  as  well  as  passed  versions  of  the  manual.  This  system 
must  satisfy  the  needs  of  a  Marine  who  is  new  to  the  Marine  Corps  as  well  as  the  veteran. 
It  is  vital  that  the  information  provided  be  accurate  and  correct  in  order  to  prevent  the 
user  from  wearing  a  uniform  or  uniform  item  against  current  policy. 
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3,  User  Skill  Level 

This  system  will  incorporate  simplicity  within  its  design.  The  initial  design  will 
be  under  the  assumption  that  the  user  has  basic  computer  operating  skills  and  web 
browsing  capabilities.  Where  applicable,  the  system  will  hide  system  complexity  from 
the  novice  while  simultaneously  appealing  to  the  expert  user. 

4,  Other  Needed  Skills 

No  additional  skill  sets  are  assessed  as  being  required  for  successful  operation  of 
the  system.  The  majority  of  interaction  the  user  will  have  with  the  system  will  involve 
“point  and  click”  functionality. 

E.  FREQUENCY  OF  SYSTEM  USE 

We  envision  the  system  being  used  on  a  daily  basis  by  thousands  of  service 
members  and  civilians  worldwide.  However,  the  average  individual  user  will  likely  only 
visit  the  site  weekly  or  biweekly. 

F.  ASSUMPTIONS  AND  DEPENDENCIES 

The  following  are  assumptions  and  dependencies  identified  for  successful  and 
timely  completion  of  the  requirements  specified  herein. 

•  No  major  loss  of  engineering  personnel 

•  No  major  changes  in  requirements  once  the  documented  requirements 
contained  within  this  RAD  are  approved 

•  Availability  of  test  personnel 

•  Individuals  are  familiar  with  web  browsing  on  their  specific  systems 

G.  SYSTEM  FUNCTIONALITIES 

1.  System  Set-Up 

The  Boundary  Use  Cases  shown  in  Section  I  identify  the  necessary  set  up 
required  for  initial  system  functionality.  These  Boundary  Use  Cases  are  further  detailed 
with  the  accompanying  sequence  diagram  in  Section  K.  The  Boundary  Use  Cases  can  be 
summarized  as  follows: 

•  The  system  must  allow  an  administrator  to  put  a  new  file  into  the  system. 

•  The  system  must  allow  an  administrator  to  edit  user  accounts  stored  in  the 
database. 


59 


•  The  system  must  allow  an  administrator  to  add  or  remove  an  award  from 
the  database. 

2.  System  Operations 

The  following  are  major  system  operations  derived  from  the  use  eases  displayed 
in  the  Use  Case  Diagram  in  Section  I  and  described  in  Section  J: 

•  Prospective  should  be  able  to  create  a  user  name  and  password  to  access 
the  site  and  set  account  information. 

•  Prospective  should  be  able  to  log-in  to  the  system  with  a  user  name  and 
password  or  enter  the  system  as  a  guest. 

•  Prospective  user  should  be  able  to  update  account  information  that  is 
currently  stored  in  the  data  base. 

•  User  should  be  able  to  search  for  a  uniform  authorized  for  own  rank. 

•  User  should  be  able  to  gather  information  and  photos  on  uniform 
regulations  for  ranks  or  genders  other  than  his  own. 

•  User  should  be  able  to  access  grooming  standards  for  a  male  or  female. 

•  User  should  be  able  to  see  awards  displayed  in  order  of  precedence  for 

their  own  awards  or  entered  awards. 

•  User  should  be  able  to  view  regulations  for  civilian  clothes. 

•  User  should  be  able  to  view  regulations  for  Physical  Training  (PT)  gear. 

•  User  should  be  able  to  view  regulations  for  organizational  clothing. 

H.  SYSTEM  ATTRIBUTES 

This  system  will  function  as  a  web  server  capable  of  displaying  interactive  pages 
to  a  user  with  containing  text  as  well  as  images.  The  web  server  will  need  to  interact  and 
exchange  information  with  a  database  which  will  hold  user  account  information  as  well 
as  images  to  be  used  and  displayed  by  the  server  at  the  request  of  the  user.  Section  K 
shows  high  level  sequence  diagrams  that  illustrate  the  interaction  between  the  user,  the 
system  and  the  database  for  the  Use  Cases  given. 

The  flow  charts  found  in  Section  L  show  the  paths  that  could  be  selected  by  the 
user  and  must  be  handled  by  the  system.  Section  M  shows  the  functionality  of  the  home 
page  of  the  system  and  illustrates  all  choices  required  by  the  user.  This  system  must 
provide  the  user  with  all  available  information  found  in  the  MCO  and  the  home  page  will 
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be  the  central  point  of  distribution.  Ail  selections  from  the  home  page  spawn  several 
different  information  paths  that  must  be  handled  by  the  system. 


I.  BOUNDARY  REQUIREMENTS 

1,  Boundary  Use  Case  Diagram 


Figure  1 .  Boundary  Use  Case  Diagram 
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2.  Boundary  Use  Cases  and  Sequence  Diagrams 

These  boundary  use  eases  deseribe  how  the  system  will  be  initialized.  They 
include  the  construction  of  the  system  files  and  also  all  data  base  input. 


Boundary  Use  Case:  BUC-1  Update  System  Files 

Primary  Actors:  System  Administrator 

Stakeholders  and  Interest: 

1.  The  system  administrator  has  created  a  file  and  desires  to  put  the  file  into  the 
system.  The  system  administrator  will  be  required  to  pass  an  identification  and 
authentication  security  requirement  in  order  to  edit  or  replace  any  files. 

Entry  conditions: 

1 .  The  system  is  operational  and  the  file  is  in  the  correct  format. 

Exit  conditions: 

1 .  The  system  makes  the  new  file  ayailable  and  the  new  file  is  properly  linked  within 
the  website. 

Elow  of  eyents: 

1 .  The  system  administrator  is  correctly  identified  and  authenticated,  gaining  access 
to  the  system’s  file  manager. 

2.  The  system  administrator  places  the  desired  file  into  the  system’s  file  structure 
either  through  the  file  transfer  protocol  (ETP)  or  another  ayailable  method. 

3.  The  system  administrator  logs  off  of  the  system,  ending  the  update  session. 

4.  The  system  maintains  a  log  of  all  eyents  during  this  session. 

Exceptions: 

*.  System  is  unayailable.  System  shows  error  message. 

la.  The  system  administrator  does  not  proyide  an  authorized  identification  or 
password. 

1.  The  system  shows  an  error  message  and  allows  for  another 
attempt. 

2.  Repeat  this  for  a  total  of  three  times  before  system  locks  for  30 
minutes. 

a.  System  updates  log  of  failed  attempt. 

b.  System  allows  the  update  capability  to  be  restored  after  30 
minutes. 

2a.  The  system  administrator  desires  to  update  or  edit  an  existing  file. 

1 .  The  system  administrator  locates  the  desired  file. 

2.  The  file  is  opened  and  changes  are  made. 

3.  The  file  is  sayed  in  the  system  with  new  changes. 

2b.  The  system  administrator  desires  to  delete  an  existing  file. 

1 .  The  system  administrator  locates  the  desired  file. 
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2. 

3. 


The  file  is  deleted  from  the  existing  files. 
The  system  updates  its  file  strueture. 


System  Administrator 


loop 


System 


< - 

- ^ 

send  acceptance 

alloyy  three  unsuccessful  logins  before  locking  system 

put(file) 

login(ID,passyyord) 


< - 

logoff 


display  updated  file  structure 


- 1 

update  file  system 


update  log  file 


Figure  2.  BUC  1 


Boundary  Use  Case: 

Primary  Aetors: 

Other  Actor: 


BUC-2  Edit  User  Accounts 
System  Administrator 
Database 


Stakeholders  and  Interest: 

1.  The  system  administrator  desires  to  edit  user  accounts  stored  in  the  database. 
Most  user  accounts  will  be  created  and  edited  by  users  as  in  UC-1  and  UC-3.  A 
system  administrator  will  also  haye  the  ability  to  edit  user  accounts. 

Entry  conditions: 

1 .  The  system  is  operational  and  the  database  is  accessible. 

Exit  conditions: 

1.  The  database  is  updated  with  the  new  information  or  the  information  is  properly 
deleted  from  the  database. 

Flow  of  eyents: 

1 .  The  system  administrator  is  correctly  identified  and  authenticated,  gaining  access 
to  edit  the  database  yia  an  administration  tool. 
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2. 


The  system  administrator  uses  the  administration  tool  to  add  new  user  account 
information. 

3.  The  changes  are  saved  on  the  database  and  the  database  is  updated. 

4.  The  system  administrator  logs  off  of  the  system,  ending  the  update  session. 

5.  The  system  maintains  a  log  of  all  events  during  this  session. 

Exceptions: 

*.  System  is  unavailable.  System  shows  error  message. 

la.  The  system  administrator  does  not  provide  an  authorized  identification  or 
password. 

1.  The  system  shows  an  error  message  and  allows  for  another 
attempt. 

2.  Repeat  this  for  a  total  of  three  times  before  system  locks  for  30 
minutes. 

a.  System  updates  log  of  failed  attempt. 

b.  System  allows  the  update  capability  to  be  restored  after  30 
minutes. 

2a.  The  system  administrator  desires  to  update  or  edit  an  existing  user 
account. 

1 .  The  system  administrator  locates  the  desired  account  information. 

2.  The  changes  are  made. 

3 .  The  database  changes  are  saved  and  the  database  is  updated. 

2b.  The  system  administrator  desires  to  delete  an  existing  user  account. 

1 .  The  system  administrator  locates  the  desired  user  account. 

2.  The  account  is  deleted  from  the  database. 

3 .  The  database  changes  are  saved  and  the  database  is  updated. 
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Boundary  Use  Case: 

Primary  Actors: 

Other  Actors: 


Figure  3.  BUG  2 

BUC-3  Update  Awards  Stored  on  Database 

System  Administrator 

Database 


Stakeholders  and  Interest: 

1.  The  system  administrator  desires  to  add  or  remoye  an  award  from  the  database. 
The  database  will  store  photographs  of  all  Department  of  Defense  approyed 
awards.  The  database  will  need  to  be  initially  populated  with  authorized  awards. 
As  new  awards  are  authorized,  the  database  will  need  to  be  updated. 

Entry  conditions: 

1 .  The  system  is  operational  and  the  database  is  accessible. 

Exit  conditions: 

1.  The  database  is  updated  with  the  new  information  or  the  information  is  properly 
deleted  from  the  database. 

Elow  of  eyents: 

1 .  The  system  administrator  is  correctly  identified  and  authenticated,  gaining  access 
to  edit  the  database  yia  an  administration  tool. 

2.  The  system  administrator  uses  the  administration  tool  to  add  a  new  photograph  of 
a  DOD  approyed  award. 

3 .  The  changes  are  sayed  on  the  database  and  the  database  is  updated. 

4.  The  system  administrator  logs  off  of  the  system,  ending  the  update  session. 
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5. 


The  system  maintains  a  log  of  all  events  during  this  session. 


Exeeptions: 

*.  System  is  unavailable.  System  shows  error  message. 

la.  The  system  administrator  does  not  provide  an  authorized  identification  or 
password. 

1.  The  system  shows  an  error  message  and  allows  for  another 
attempt. 

2.  Repeat  this  for  a  total  of  three  times  before  system  locks  for  30 
minutes. 

a.  System  updates  log  of  failed  attempt. 

b.  System  allows  the  update  capability  to  be  restored  after  30 
minutes. 

2a.  The  system  administrator  desires  to  delete  an  existing  award  photograph. 

1 .  The  system  administrator  locates  the  desired  photograph. 

2.  The  photograph  is  deleted  from  the  database. 

3.  The  database  changes  are  saved  and  the  database  is  updated. 


Figure  4.  BUG  3 
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J.  USE  CASES 

Use  case:  UC-1  Set  Up  Account 

Primary  Actor:  Prospective  User 

Other  Actor:  Data  Base 

Stakeholders  and  Interest: 

1 .  Prospective  user  wants  to  create  a  user  name  and  password  to  access  the  site  and 
set  account  information. 

Entry  conditions: 

1 .  System  is  operational. 

2.  Prospective  user  has  access  to  the  internet  and  the  system  is  accessible. 

3.  Prospective  user  has  correctly  entered  the  URL  into  a  browser  and  the  system  has 
responded  with  the  log  in  page. 

Exit  conditions: 

1 .  Prospective  user  completes  the  required  account  information  inputs  and  is  sent  a 
verification  of  account  set  up  by  the  system. 

Plow  of  events: 

1 .  Prospective  user  selects  the  new  user  link  from  the  log  in  page. 

2.  System  displays  the  account  information  page  with  required  input  fields. 

3 .  Prospective  user  fills  in  the  account  information. 

4.  Prospective  user  submits  account  information. 

5 .  System  updates  internal  database  with  new  information. 

6.  System  sends  a  verification  of  a  successful  account  set  up. 

Exceptions: 

*.  The  prospective  user  cancels  the  procedure  at  any  time.  All  the  data  are  purged  from 
the  system. 

2a.  Page  is  not  available  to  be  returned  to  the  user. 

1 .  System  displays  an  error  message. 

2.  Repeat  step  1  in  flow  of  events. 

5a.  System  rejects  application  due  to  inadequate  information. 

1 .  System  directs  Prospective  user  to  complete  affected  areas  of  application. 

2.  Repeat  step  3  in  flow  of  events. 

5b.  System  rejects  application  due  to  duplication  found  in  user  name. 

1.  System  directs  the  Prospective  user  to  use  a  different  user  name 
for  this  account. 

6a.  System  fails  to  send  a  verification  message. 

1 .  Repeat  step  1  in  flow  of  events. 
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Use  case:  UC-2  Log-In 

Primary  Actors:  Prospective  User 

Other  Actor:  Data  Base 

Stakeholders  and  Interest: 

I .  Prospective  user  wants  to  access  the  system. 

Entry  conditions: 

1.  UC-I  completed. 

2.  System  is  operational. 

3.  Prospective  user  has  access  to  the  internet  and  the  system  is  accessible. 

4.  Prospective  user  has  correctly  entered  the  URL  into  a  browser  and  the  system  has 
responded  with  the  log  in  page. 

Exit  conditions: 

1 .  User  has  successfully  logged  in  to  the  system. 

Elow  of  events: 

1 .  User  enters  user  name  and  password  in  order  to  access  the  system. 

2.  The  system  validates  the  entered  information. 

a.  In  case  data  is  invalid:  Inform  the  customer  and  proceed  to  step  (2) 

b.  In  case  data  is  valid: 

1 .  System  displays  the  home  page. 

2.  Personalized  welcome  message  displayed  on  home  page. 

3.  System  filters  all  information  according  to  account  information 
such  as  rank,  gender,  awards,  etc. 

Exceptions: 

*a.  Customer  is  locked  out  after  three  (3)  unsuccessful  attempts  to  log-on. 

la.  User  forgets  user  name  or  password. 

1 .  User  selects  the  forgotten  user  name/password  link. 

a.  System  sends  a  blank  information  page  with  inputs  for: 

East  Name 
Eirst  Name 
Rank 
Gender 

E-Mail  address 
User  Name 
Password 

b.  User  must  input  at  least  four  fields. 

c.  System  verifies  these  four  fields. 

1 .  If  the  fields  verity  successfully,  system  e-mails  user  name  and  password  to  e-mail 
address. 
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2. 


If  the  fields  eannot  be  verified,  the  system  notifies  the  user. 


Use  ease:  UC-3  Update  Aeeount  Information 

Primary  Aetors:  Prospeetive  User 

Other  Aetor:  Data  Base 

Stakeholders  and  Interest: 

1 .  Prospeetive  user  wants  to  update  his  aeeount  information  that  is  eurrently  stored 
in  the  data  base. 

Entry  eonditions: 

1 .  UC- 1 ,  Set  Up  Aeeount,  eompleted. 

2.  UC-2,  Log-In,  eompleted. 

Exit  eonditions: 

1 .  User  has  sueeessfully  updated  aeeount  information. 

Elow  of  events: 

1 .  User  seleets  the  update  personal  information  link  from  the  home  page. 

2.  The  system  displays  all  eurrent  fields  stored  in  the  database. 

3.  User  updates  one  or  more  fields  with  new  information. 

4.  System  updates  the  database  with  new  information. 

5.  System  sends  a  verifieation  of  a  sueeessful  aeeount  update. 

Exeeptions: 

*.  The  prospeetive  user  eaneels  the  proeedure  at  any  time.  All  the  new  data  are  purged 
from  the  system  and  old  data  are  restored. 

4a.  System  rejeets  application  due  to  duplication  found  in  user  name. 

1 .  System  directs  the  Prospective  user  to  use  a  different  user  name  for 
this  account. 

5a.  System  fails  to  send  a  verification  message. 

1 .  Repeat  step  1  in  flow  of  events. 


Use  case:  UC-4  Choose  Uniform  for  Own  Rank 
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Primary  Actors:  Prospective  User 

Other  Actor: 


Stakeholders  and  Interest: 

1 .  User  wants  to  find  a  uniform  authorized  for  own  rank. 

Entry  conditions: 

1 .  UC- 1 ,  Set  Up  Account,  completed. 

2.  UC-2,  Log-In,  completed. 

3.  System  has  filtered  available  information  based  on  the  user’s  account  information 
Exit  conditions: 

1 .  System  displays  the  desired  uniform. 

Elow  of  events: 

1 .  User  selects  a  particular  type  of  uniform  from  the  following  list: 

Evening  Dress 
Blue  Dress 
Service 

Combat  Utility 
Specialty 

2.  System  displays  the  sub-categories. 

3.  User  selects  a  particular  uniform  from  the  sub-categories. 

a.  System  displays  photo  of  the  selected  uniform. 

b.  System  displays  text  from  Marine  Corps  Order  (MCO). 

Exceptions: 

*.  System  unable  to  display  selected  information.  System  shows  error  message, 
la.  User  wants  to  change  selection  to  a  different  type  of  uniform. 

1 .  Repeat  step  1  from  flow  of  events. 

3  a.  User  wants  to  change  selection  to  a  different  type  of  uniform. 

1 .  User  selects  “new  uniform  type”  link. 

2.  Repeat  step  1  from  flow  of  events. 

3b.  User  wants  to  change  selection  to  a  different  uniform  within  the  same 
type. 

1 .  Repeat  step  3  from  flow  of  events. 
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Use  case:  UC-5  Choose  Uniform  From  Any  Rank/Gender 

Primary  Actors:  Prospective  User 

Other  Actor: 

Stakeholders  and  Interest: 

1 .  User  wants  to  gather  information  and  photos  on  uniform  regulations  for  ranks  or 
genders  other  than  his  own. 

Entry  conditions: 

1 .  UC- 1 ,  Set  Up  Account,  completed. 

2.  UC-2,  Log-In,  completed. 

3.  System  has  filtered  available  information  based  on  the  user’s  account  information 
Exit  conditions: 

1 .  System  displays  uniform  for  any  selected  rank  or  gender. 

Elow  of  events: 

1 .  User  changes  the  rank  to  the  desired  rank. 

2.  System  filters  available  information  to  selected  rank. 

3.  System  disables  personal  awards  feature  that  displays  the  user’s  awards. 

4.  User  changes  the  gender  to  the  desired  gender. 

5.  System  filters  available  information  to  selected  gender. 

6.  User  selects  a  particular  type  of  uniform  from  the  following  list: 

Evening  Dress 
Blue  Dress 
Service 

Combat  Utility 
Specialty 

7.  System  displays  the  sub-categories. 

8.  User  selects  a  particular  uniform  from  the  sub-categories. 

a.  System  displays  photo  of  the  selected  uniform. 

b.  System  displays  text  describing  the  uniform  in  accordance  with  Marine  Corps 
Order  (MCO). 

Exceptions: 

*.  System  unable  to  display  selected  information.  System  shows  error  message, 
la.  User  desires  to  change  to  any  rank  at  any  time. 

1 .  Repeat  step  1  from  flow  of  events. 

4a.  User  desires  to  change  gender  at  any  time. 

1 .  Repeat  step  4  from  flow  of  events. 

6a.  User  wants  to  change  selection  to  a  different  type  of  uniform. 

1 .  Repeat  step  6  from  flow  of  events. 

8a.  User  wants  to  change  selection  to  a  different  type  of  uniform. 

1 .  User  selects  “new  uniform  type”  link. 

2.  Repeat  step  6  from  flow  of  events. 

8b.  User  wants  to  change  selection  to  a  different  uniform  within  the  same  type. 

Repeat  step  8  from  flow  of  events: 
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Use  case:  UC-6  Display  Measurements  for  Uniform  Items 

Primary  Actors:  Prospective  User 

Other  Actor: 


Stakeholders  and  Interest: 

I.  User  desires  measurement  specifications  for  any  part  of  the  uniform  such  as 
trouser  length,  belt  length,  blouse  arm  length  etc. 

Entry  conditions: 

1.  UC-4,  Choose  Uniform  for  Own  Rank  or  UC-5,  Choose  Uniform  From  Any 

Rank/Gender  completed. 

Exit  conditions: 

1 .  System  displays  desired  measurements  on  photo  and  also  displays  the 
corresponding  text  from  the  MCO. 

Flow  of  events: 

1 .  User  mouses  over  hotspots  that  dissect  the  photo  of  the  desired  uniform. 

2.  System  magnifies  the  area  as  it  is  moused  over. 

3.  User  selects  desired  area. 

4.  System  displays  a  short  description  on  the  photo. 

5.  System  displays  the  detailed  verbiage  associated  with  the  selected  area  in 
accordance  with  MCO. 

Exceptions: 

*.  System  unable  to  display  selected  information.  System  shows  error  message. 

3a.  User  desires  to  select  a  different  area. 

1.  Repeat  step  3. 
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Use  case:  UC-7  Display  Grooming  Standards 

Primary  Actors:  Prospective  User 

Other  Actor: 


Stakeholders  and  Interest: 

1.  User  desires  the  USMC  grooming  standards.  The  grooming  standards  can  be 
accessed  by  a  link  from  the  main  menu  or  from  any  photo  of  a  desired  uniform. 

Entry  conditions: 

1 .  UC-2,  Log-In,  completed. 

Exit  conditions: 

1.  System  displays  desired  grooming  standards  on  photo  and  also  displays  the 
corresponding  text  from  the  MCO. 


Elow  of  events: 

1 .  User  desires  information  regarding  grooming  standards. 

a.  User  selects  grooming  standards  link  from  the  main  menu. 

a.  System  displays  a  large  view  of  the  head  area  with  hotspots 
that  dissect  the  area  further. 

b.  User  mouses  over  hotspots  of  the  head  area  on  the 
displayed  photo  as  in  UC-6. 

1 .  System  magnifies  the  area  as  it  is  moused  over. 

2.  User  selects  desired  area. 

3.  System  displays  a  large  view  of  the  head  area  with 
hotspots  that  dissect  the  area  further. 

2.  User  selects  the  specific  area  desired. 

3 .  System  displays  a  short  description  on  the  photo. 

4.  System  displays  the  detailed  verbiage  associated  with  the  selected  area  in 
accordance  with  MCO. 


Exceptions: 

*.  System  unable  to  display  selected  information.  System  shows  error  message, 
la.  User  selects  a  different  link  from  the  main  menu. 

2a.  User  desires  a  different  area. 

1 .  Repeat  step  2  in  flow  of  events. 
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Use  case:  UC-8  Display  Awards  Precedence 

Primary  Actors:  Prospective  User 

Other  Actor:  Database 

Stakeholders  and  Interest: 

1 .  User  desires  to  see  the  display  in  order  of  precedence  of  own  awards  or  entered 
awards.  The  awards  can  be  accessed  from  the  main  menu  or  from  linking  to  the 
hotspot  found  on  the  main  photo  as  in  UC-6,  Display  Measurements  for  Uniform 
Items. 

Entry  conditions: 

1 .  UC- 1 ,  Set  Up  Account,  completed. 

2.  UC-2,  Log-In,  completed. 

3.  If  the  awards  are  to  be  accessed  from  the  displayed  photo  vice  the  main  menu, 
UC-6,  Display  Measurements  for  Uniform  Items,  must  be  completed. 

Exit  conditions: 

1.  System  displays  the  photos  of  the  desired  awards  in  the  correct  order  of 
precedence  in  accordance  with  the  MCO. 

Elow  of  events: 

1 .  User  desires  to  view  awards  precedence  or  measurements  of  awards  and  insignias 
as  stored  under  his  user  name. 

a.  User  selects  awards  from  the  main  menu  or  user  selects  the  awards  hotspot 

found  on  the  displayed  photo  as  in  UC-6,  Display  Measurements 
for  Uniform  Items. 

b.  System  accesses  the  data  base  and  retrieves  the  previously  stored 
information  as  created  in  UC-1,  Set  Up  Account. 

2.  User  desires  to  view  awards  precedence  or  measurements  of  any  awards. 

a.  User  selects  the  input  awards  link. 

b.  User  inputs  the  desired  awards  and  insignias. 

3.  The  system  retrieves  all  images  to  corresponding  awards  and  arranges  them  in 
order  of  precedence  in  accordance  with  MCO. 

4.  The  system  displays  the  images  along  with  the  correct  measurements  of  awards 
and  insignias  in  accordance  with  MCO. 

Exceptions: 

*.  System  unable  to  display  selected  information.  System  shows  error  message, 
la.  User  desires  to  update  existing  awards  data  base. 

1 .  User  selects  update  awards  link. 
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2.  User  changes  account  information  as  in  UC-3,  Update  Account 
Information. 

3.  Repeat  step  1  in  flow  if  events. 


K.  SEQUENCE  DIAGRAMS 

Set  Up  Account: 


Figure  6.  Set  Up  Account 


Log-In: 


Figure  7.  Log-In 
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Update  Account  Information; 


Prospective  User 


System 


updateAccount 

< - 

W 

display  Account  Information 

update  Account  Information  ^ 

^ - 

verify  Nev^  Information 

concur  with  New  Information  ^ 

< - 

verify  updates 

get  Account  Information 


update  Account  Information 


Figure  8.  Update  Account  Information 


Data  Base 


> 
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Choose  Uniform  for  Own  Rank: 


Prospective  User 


System 


select  uniformType  ^ 

« - 

display  uniform  sub-categories 

Cs 

All  uniforms  will  fall  into  a  hierarchy. 

For  example,  service  uniforms  will 
contain  the  sub-categories  of  Service  A, 
Service  B,  and  Service  C. 

select  uniform 

- ^ 

display  photo 


display  text 


Figure  9.  Choose  Uniform  for  Own  Rank 
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Choose  Uniform  From  Any  Rank/Gender: 


Figure  10.  Choose  Uniform  From  Any  Rank/Gender 
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Display  Measurements  for  Uniform  Items: 


Figure  1 1 .  Display  Measurements  for  Uniform  Items 
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Display  Grooming  Standards: 


Prospective  User 


System 


selectGroomingStandards 


< 

- w 

display  view  of  head  with  hotspots 

The  view  of  the  head  will  be  of  the  same  gender  selected  for  uniform  type 

mouseOverHotSpots 

^ 

< - 

selectHotSpot 

magnify  selected  area 

- ^ 

display  photo 
display  text 


The  text  displayed  will  be  grooming  standards  in  accordance  with  MCO 


Figure  12.  Display  Grooming  Standards 
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Display  Awards 
Precedence: 


Prosoective  User 

Svstem 

Data  Base 

selectAwards 


- ^ - 1\ 

This  can  be  done  from  the  main  menu  or  from  the  hotspot 
found  on  the  displayed  photo  as  in  UC-6,  Display 
Measurements  for  Uniform  Items. 


display  awards 


display  text 


Figure  13.  Display  Awards  Precedence 
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FLOW  CHARTS 


User 

V _ ^ 


Account 

Setup 


Account 
Last  Name 
First  Name 
Gender 
Rank 
Awards 
User  Name 
Password 
MOS 
E-mail 


Stored 


Database 
Accounts 
Award  Pictures 


Create 

Account? 


Enter  as 
Guest? 


Show 

Guest 

Homepage 


r  ^ 

start  Page 

\ _  ) 


Account 


No 

(After  3  tries: 
block  IP) 


Verify  with  database 


Remember 
Password\ 
User  Name? 


-yes^ 


r  ^ 

Enter  ID/PW 


GetPassword/ 

Username 

Last  Name 

First  Name 

Gender 

Rank 

Awards 

User  Name 

Password 

MOS 

E-mail 


Verify 


yes 


E-mail 

Password 


Verify  with  database 

Figure  14.  Flow  Chart  1 


Verify 


Show 

User 

Homepage 
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yes 


Figure  15.  Flow  Chart  2 
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M.  HOME  PAGE  INFORMATION 
I.  Home  Page  Selections 


Uniforms 

Grooming  Standards 
Awards 

Civilian  Clothes 
PT  Gear 
Musieal  Units 
Organizational  Clothing 
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2. 


Home  Page  Flow  Charts 


Figure  16.  Home  Page  Flow  Chart 


Show  photograph  as 
indicated  in  figure  1 
below. 
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Footwear 


Rank 


Insignia 

and 

Buttons 


Blouse/ 

Jacket 


Belt 


Sleeve 

Length 


Trousers 


Trouser 

Length 


Grooming 

Standards 


Medals/ 

Ribbons 


Overlap 
Measurements 


Optional  Items 

Gloves 

Sword 

Overcoat 

Sam  Brown  Belt 

Etc. 


Cover 


Figure  17.  Typical  Sections  for  a  Photograph 
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Organizatio 
nal  Clothes 


Brassa 


Moumins 


Military  Dolice 


Field  Coat 


Fleadgear, 


Food  service 


Flonor  guard 


Campaign 

Service 

Organizational 

clothing 


Marine  securitv 


Shore  nartv 


Breastco 


Flight 


Show  description 
of  selected 
organizational 
clothing. 


Figure  19.  Organizational  Menu 
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II.  SOFTWARE  DESIGN  SPECIFICATIONS  (SDS) 


A.  REVISION  SHEET 


Revision  Number 

Date 

Brief  Description  of  Changes 

001 

26  Feb  2006 

Version  1  completed  and  submitted  to  Prof.  Shing 

B,  INTRODUCTION 

1.  Purpose 

The  purpose  of  the  Software  Design  Speeification  (SDS)  is  to  describe  the 
functionality  of  the  Web  Based  Uniform  Manual.  The  SDS  will  be  presented  to  the 
customer  for  review,  comment,  and  validation  of  the  design.  This  document  describes 
the  subsystems  and  modules  that  form  the  Graphical  User  Interface,  server  requirements, 
and  Database  requirements.  The  SDS  provides  highly  detailed  technical  data,  system 
information,  and  other  relevant  information  on  the  Web  Based  Uniform  Manual.  This 
document  includes  an  architecture  diagram,  a  design  class  diagram,  interaction  diagrams, 
state  diagrams,  and  a  glossary. 

2.  Scope  and  Audience 


90 


The  web  based  manual  deseribed  in  this  doeument  will  be  in  striet  accordance 
with  MCO  P1020.34G.  This  system  will  be  relied  on  by  Marines  world  wide  as  an 
accurate  source  of  standards  that  ensure  their  compliance  with  the  MCO.  The  new 
design  will  be  lAW  the  principles  of  HCI  and  will  support  quick  links  and  menu  driven 
systems  that  will  allow  all  relevant  information  to  be  displayed  or  hidden  as  the  user 
requires.  The  new  system  will  address  all  aspects  currently  outlined  in  the  regulations, 
such  as  proper  wearing  of  the  uniform,  grooming  standards,  ribbon  and  medal 
precedence,  civilian  attire,  PT  gear,  and  optional  items  for  male  and  female  officers  and 
enlisted  U.  S.  Marines.  This  system  could  be  used  by  all  US  civilians  and  military 
service  members  to  whom  the  current  manual  is  now  relevant. 

3,  Goal  Statement 

The  overall  goal  of  the  project  will  be  to  create  an  easy  to  use  GUI  based  uniform 
regulation  guide.  This  system  will  be  web  based  and  will  be  designed  to  accommodate 
further  maintenance  and  reuse. 

4,  Implementation  &  Special  Features 

The  guide  will  be  implemented  using  primarily  visual  aides  and  follow  the 
practices  of  good  Macro/Micro  HCI  Design.  The  aim  will  be  to  provide  the  needed 
information  to  the  user  in  an  easy  to  use  GUI  interface  that  requires  minimal  “mouse 
clicks”  to  retrieve  the  desired  information.  The  guide  will  also  provide  the  user  with 
alternative  text  from  the  Marine  Corps  Order  P1020.34G  dealing  with  the  specific 
uniform  in  question.  The  end  result  will  be  an  easy  to  use  research  tool  that  may  be 
utilized  by  members  of  the  United  States  Marine  Corps  to  ensure  that  their  uniform  is 
within  regulations. 

5,  System  Use 

The  use  of  the  system  will  support  quick  links  and  menu  driven  systems  that  will 
allow  all  relevant  information  to  be  displayed  or  hidden  as  the  user  requires.  The  new 
system  will  address  all  aspects  currently  outlined  in  the  regulations  and  described  in  the 
Requirements  Analysis  Document  referenced.  This  system  will  be  used  by  all  US 
civilians  and  military  service  members  to  whom  the  current  manual  is  now  relevant. 

6,  REFERENCES 
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•  Larman,  Craig.  Applying  UML  and  Patterns:  an  introduction  to  object 
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C.  HCI  DESIGN  AND  JUDGMENT  CATEGORIES 

1.  Simplicity 

Simplicity  provides  the  means  by  which  the  web  page  aims  to  keep  the  basic 
utility  of  the  interface  easy  to  use,  and  offer  facilities  which  are  of  a  clear  value  to  the 
military  member.  The  interface  should  be  intuitive  and  there  should  be  no  question  as  to 
how  to  use  this  manual. 

2.  Consistency 

The  user  should  feel  that  he  or  she  is  in  control  and  that  the  system  is  responding 
to  his  or  her  actions  accordingly.  Users  should  have  control  over  the  amount  of 
information  they  receive  at  different  points  of  the  interaction.  During  the  interaction,  the 
web  page  should  have  a  common  look  and  presentation  that  is  presentable  and 
professional.  As  shown  in  Eigure  16,  this  manual  will  be  broken  up  into  four  main 
categories;  male  officer,  male  enlisted,  female  officer,  female  enlisted.  During 
exploration  of  this  manual,  each  category  will  be  easily  identified.  This  will  allow  for 
ease  of  presence  within  this  site. 
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Figure  20.  Four  Main  Categories 


3.  Control 

Control  notions  initiated  by  the  user  should  reoeive  the  appropriate  responses. 
Error  and  control  messages  should  generate  the  same  responses  throughout  this  site. 

4.  Shortcuts  and  Customization 

The  web  page  should  present  mechanisms  for  users  to  customize  settings  to  speed 
frequency  of  use  by  users. 

5.  Screen  layout 

The  screen  layout  should  give  an  appearance  of  clarity  with  the  proper  use  of 
white  space  to  separate  items.  Items  should  be  presented  in  a  balanced  fashion,  and  not 
distort  during  screen  resolution  change.  Additionally,  control  maneuvers  should  be 
reachable  without  scrolling  extensively. 

6.  Feedback 

Appropriate  feedback  before,  during,  and  after  interaction  is  essential  to  proper 
HCI.  Prompts  and  directions  should  be  provided  to  the  user  at  all  times.  The  user  should 
never  be  left  in  a  state  of  question. 

7.  Error  Handling 

There  shall  be  no  means  of  deleting  or  changing  information.  This  action  will 
allow  the  user  freedom  of  experimentation  without  degradation  of  the  information 
presented  on  this  site.  This  will  ensure  error  handling  is  at  a  minimum  in  regards  to 
development  of  this  site. 
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8,  Efficiency 

All  accessible  elements  of  the  web  page  are  generated  in  a  timely  manner.  The 
information  provided  within  this  site  will  be  in  conjunction  with  the  latest  regulation 
regarding  the  speeifie  uniform  in  question.  In  an  effort  to  speed  efficieney,  a  “SEARCH” 
feature  should  also  be  implemented.  The  added  feature  will  allow  expert  users  extended 
usability  of  this  manual. 

9,  Help  Facilities 

The  web  page  will  provide  a  mechanism  to  report  problems  or  errors.  Additional 
help  facilities  regarding  military  uniform  regulations  will  also  be  provided. 

10,  Navigation 

Navigation  within  the  web  presenee  should  be  easily  aehieved  with  minimal 
“elieks”  or  drop  down  menus  to  aehieve  a  desired  result. 

11,  Objects 

Each  major  category  will  have  similar  index  pages  and  file  structures.  The 
objects  that  will  be  created  from  the  index  page  as  the  user  completes  a  search  for  desired 
information  are  shown  in  Eigure  17.  Generic  layouts  for  other  pages  are  shown  in 
Eigures  18  and  19.  These  are  not  objects  as  normally  recognized  in  object  oriented 
programming,  but  we  refer  to  them  as  objects  for  explanatory  purposes.  Since  this  entire 
system  is  web  based,  objects  are  not  truly  created  but  rather  each  selection  calls  a  desired 
page  within  the  web  server. 
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Navigation  Bar 
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Figure  2 1 .  Index  Page  Layout 
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Links 
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Detailed  Text  from  Marine  Corps  Order  P1020,34G  MCO 

Figure  22.  Typieal  Uniform  Page  Layout 
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Navigation  Bar 

Home  Evening  Blue  Dress  BlueAVhite  Dress  Service  Utility 

Optional 

Items 

Main  Photo  Area 

Detailed 

Sections 

Detailed  Text  from  Marine  Corps  Order  P1020,34G  MCO 

Figure  23.  Typical  Uniform  Type  Page  Layout 

D,  MAINTAINABILITY 

This  system  must  be  designed  in  order  to  allow  for  easy  maintenance.  The 
designers  of  this  system  will  not  be  responsible  for  any  future  maintenance  of  this 
system.  It  is  our  intention  to  build  this  site  and  turn  all  files  over  to  Headquarters  Marine 
Corps  for  implementation.  Our  design  goal  is  to  allow  this  site  to  be  usable  for  many 
years  to  come  within  the  Marie  Corps.  This  can  only  be  achieved  if  the  site  is  easily 
maintainable  and  files  can  be  edited  or  deleted  as  the  MCO  changes.  In  order  to  achieve 
the  desired  maintainability,  the  design  must  adhere  to  the  following: 

1.  Reliability 

The  reliability  of  this  system  will  be  dependent  on  the  stability  of  the  code  and  the 
capacity  for  system  upgrades.  The  design  of  this  system  will  be  done  with  the  goal  of 
system  reliability  in  mind. 

2.  Efficiency 

This  system  must  be  designed  to  maximize  the  efficiency  of  the  code.  This  will 
be  done  by  inhibiting  overloading  and  preventing  unnecessary  parts  of  the  code.  All 
written  code  will  be  thoroughly  scrubbed  for  gratuitous  code  or  fdes. 
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3,  Understandability 

This  will  be  a  key  aspeet  to  maintaining  this  site.  The  doeumentation  provided 
here  as  well  as  the  strueture  of  the  files  will  help  future  maintainers  to  understand  the  site 
and  assist  in  implementing  any  changes.  It  is  unknown  as  to  the  technical  expertise  and 
experience  of  the  future  maintainer  of  this  site  so  full  documentation  is  critical. 

4,  Measurability 

Software  metrics  can  be  used  to  estimate  the  project  budget  and  schedule, 
evaluate  individual  productivity  and  quality,  evaluate  project  productivity  and  quality, 
and  evaluate  the  system  quality. 

E,  REUSE 

The  design  specifications  for  this  system  call  for  the  design  of  a  web  based 
uniform  manual  for  the  United  States  Marine  Corps.  However,  the  same  need  can  be 
paralleled  to  any  service  within  the  Department  of  Defense  or  any  international  military 
organization.  This  system  will  be  designed  with  the  concept  of  reuse  in  mind.  The 
system  developed  here  can  be  easily  transferred  into  any  other  service  branch.  This  will 
be  done  with  a  file  structure  that  is  generic  enough  to  allow  for  the  input  of  any  uniform 
type  and  a  system  structure  that  can  support  any  similar  specification. 


F.  SECURITY 

The  information  on  this  site  needs  to  be  in  complete  compliance  with  Marine 
Corps  Order  P1020.34G.  Any  deviations  from  this  standard  render  this  site  useless.  The 
threat  of  hackers  is  always  present  when  dealing  with  the  web  based  systems.  If  any  user 
can  break  through  and  change  any  of  the  information  on  our  website,  it  will  sacrifice  the 
integrity  of  the  information  posted.  Once  the  information  is  found  to  be  inaccurate,  it 
will  render  our  system  unreliable  and  discourage  its  use. 

G.  SYSTEM  ARCHITECTURE 

The  Web  Based  Uniform  Regulations  Manual  is  organized  into  a  three-tier  closed 
architecture  composed  of  a  presentation  layer,  application  logic  layer  (domain),  and 
storage/network  layer  (services).  The  purpose  of  this  organization  is  to  promote  reuse, 
support  distributed  processing,  and  allow  parallel  team  development.  Also,  by  building 
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each  layer  only  in  terms  of  each  immediate  lower  layer,  this  design  will  reduce 
dependencies  between  each  layer  enabling  the  system  to  be  combined  with  other 
hardware/software  platforms  with  minimal  rewriting  of  single  layers. 

The  System  Architecture  decomposes  the  Web  Based  Uniform  Regulations 
Manual  system  into  subsystems  by  vertical  layers  and  horizontal  partitions.  The 
presentation,  domain,  and  service  top  layers  are  represented  by  the  common  graphical 
user  interface  (GUI),  CTF  Infrastructure,  and  Computer  Website  services  subsystems 
respectively.  Figure  20  illustrates  the  organization  of  subsystem  layers  and  partitions 
within  the  Web  Based  Uniform  Regulations  Manual  System  Architecture. 
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Figure  24.  System  Arehiteeture  Diagram 


H.  PRESENTATION  LAYER 

A  web  browser  will  funetion  as  the  elient  interfaee.  Its  sole  purpose  is  the  display 
of  the  Web  server  generated  HTML  pages.  To  ereate  a  platform  independent  experienee 
the  page  layout  will  be  eontrolled  by  Caseading  Style  Sheets.  These  style  sheets,  onee 
eaehed  by  the  browser,  will  also  aeeount  for  faster  webpage  loading.  All  eontent  ereation 
will  be  done  by  server  side  PHP  seripting,  again  eontributing  to  a  browser  independent 
display  without  the  need  for  elient  side  browser  plugins  (like  Java  seript),  thus  speeding 
up  the  page  load  time  and  avoiding  safety  eritieal  seripting  on  the  elient  eomputer.  This 
will  also  allow  handheld  deviees,  whieh  are  not  always  equipped  with  seripting  eapable 
browser,  to  load  and  display  the  interfaee  pages. 
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Figure  25.  Context  Diagram 

I.  APPLICATION  LAYER 

The  middle  tier  is  divided  in  two  units  with  different  functions.  An  intermediate 
layer  (web  server)  implemented  in  a  scripting  language  (PHP).  This  layer  receives 
requests  from  the  Internet  clients  and  generates  html  using  the  services  provided  by  the 
storage/infrastructure  layer.  This  additional  layer  provides  isolation  between  the 
application  layout  and  the  application  logic. 

This  system  will  be  designed  to  reside  on  an  Apache  Web  Server.  The  Apache 
Web  Server  has  several  advantages.  It  is  extremely  powerful,  modular,  flexible,  highly 
configurable,  and  extensible.  It  is  freely  available  through  open  source  which  means  that 
its  source  code  is  examined  constantly  by  numerous  users.  This  constant  examination  by 
outsiders,  makes  it  substantially  more  reliable  than  any  commercial  software  product  that 
can  only  rely  on  the  scrutiny  of  a  closed  list  of  employees.  Apache  currently  runs  on 
approx.  68-70%  of  all  web  servers  worldwide  making  it  the  #1  choice  of  web  servers 
since  1996.  This  makes  it  the  most  secure  web  server  worldwide. 

J.  STORAGE/INFRASTRUCTURE  LAYER 

The  basic  design  philosophy  that  we  will  follow  is  to  create  four  complete  and 
separate  sites  that  can  actually  completely  stand  alone  and  have  a  common  link  from  the 
login  page  as  shown  in  Figure  22. 
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Figure  26.  Site  Layout 


This  type  of  architecture  will  allow  us  to  extensively  test  while  developing  the 
site.  We  can  first  create  the  Male  Officer  “site”  in  its  entirety  and  test  this  module.  Then 
we  can  create  the  login  page  and  develop  its  functionality.  Once  the  login  page  is  linked 
to  the  Male  Officer  “site”,  we  can  exhaustively  test  this  smaller  system  and  develop  it 
completely.  Then  it  would  simply  be  a  duplication  of  the  Male  Officer  “site”  in  order  to 
create  the  Female  Officer  “site”,  the  Male  Enlisted  “site”,  and  the  Female  Enlisted  “site” 
(allowing  for  the  subtle  nuances  of  each  subcategory).  The  final  step  in  architecture 
design  will  be  to  link  all  four  subcategories  to  each  index  page.  Eor  example,  if  a  user  is 
currently  in  the  Male  Officer  “site”  and  he  desires  to  look  at  female  enlisted  uniforms,  he 
can  quickly  access  the  index  page  of  the  Eemale  Enlisted  “site”  and  now  navigate  through 
that  “site”. 

1.  File  Naming 

All  four  subcategories  will  share  the  same  file  names  as  shown  in  figure  23.  This 
will  allow  for  the  quick  creation  of  the  remaining  subcategories  after  the  first  one  is 
created.  This  type  of  file  naming  pattern  lends  is  attainable  since  all  ranks  and  genders 
within  the  USMC  must  follow  the  same  manual.  Also  all  ranks  and  genders  within  the 
USMC  have  the  same  uniform  names  but  the  style  of  the  uniform  varies  between  ranks 
and  gender.  A  clear  and  concise  file  structure  is  imperative  for  construction  of  this  site 
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and  to  ensure  maintainability.  All  files  need  to  be  arranged  in  a  manner  that  is  easy  to 
follow  and  is  unambiguous  since  this  system  will  not  be  maintained  by  the  original 
design  team. 

2,  File  Layout 

All  files  will  be  placed  in  one  of  four  substructures  that  are  referenced  from  a 
main  index  page.  As  mentioned  earlier  in  this  document,  the  files  will  be  broken  up  into 
four  main  categories;  male  officer,  male  enlisted,  female  officer,  female  enlisted.  Figure 
23  shows  the  file  structure  for  male  officers.  This  structure  will  be  repeated  for  all  other 
categories. 
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Figure  27.  File  Structure 

3,  Database 

The  Relational  Database  MySQL  provides  the  persistent  storage  for  user  specific 
data.  It  will  communicate  with  the  presentation  layer  via  the  PFIP  scripting  language. 

4,  Security 

Apache  provides  security-related  configuration  directives  enabling  administrators 
to  tighten  the  security: 
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•  User  /  Group:  Defines  user/group  Apache  should  run  as 

•  LimitRequestBody:  Restrict  total  size  of  HTTP  request  body  sent  from  a 
client 

•  LimitRequestFields:  Limit  number  of  HTTP  request  header  fields  that  will 
be  accepted  from  the  client 

•  LimitRequestFieldSize:  Limit  size  of  the  HTTP  request  header  allowed 
from  the  client 

•  LimitRequestLine:  Limits  overall  size  of  the  HTTP  request  line  that  will 
be  accepted 

•  Listen:  Defines  the  IP  addresses  and  ports  the  server  listens  on 

•  ServerTokens:  Server  HTTP  response  header 

•  ServerSignature:  Content  of  footer  available  on  server-generated 
documents 

•  SSLEngine:  Toggle  usage  of  SSL/TLS  protocol  engine 

•  UserDir:  Indicates  the  location  of  user-specific  directories 

K.  CLASS  MODEL 

Figure  24  of  this  document  shows  the  system’s  SCRS  Class  Diagram.  It  illustrates 
the  basic  context  in  which  the  whole  SCRS  system  operates. 
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Figure  28.  Class  Diagram 
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Figure  29.  Class  Diagram 


L.  LOGIN  PAGE 

1,  verifyUserPasswordO 

A  password  is  provided  by  the  user  and  passed  by  the  web  browser  to  the  system. 

2,  getMaleOfficerlndexQ 

Used  to  get  the  index  page  of  the  Male  Officer  Subcategory. 

3,  getMaleEnlistedIndexO 

Used  to  get  the  index  page  of  the  Male  Enlisted  Subcategory. 

4,  getFemaleOfficerlndexQ 

Used  to  get  the  index  page  of  the  Female  Officer  Subcategory. 

5,  getFemaleEnlistedlndexQ 

Used  to  get  the  index  page  of  the  Female  Enlisted  Subcategory. 

6,  createAccountQ 

The  user  desires  to  create  a  new  account  which  is  passed  to  the  system  by  the  web 
browser. 

7,  forgotUserPasswordO 
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The  user  needs  a  reminder  of  his  password  whieh  is  passed  to  the  system  by  the 
web  browser. 

M.  ACCOUNT 

1,  lastName:  String 

Used  for  the  last  name  of  the  user  account. 

2,  firstName:  String 

Used  for  the  first  name  of  the  user  account. 

3,  gender:String 

Used  for  the  gender  of  the  user  account. 

4.  rank:  String 

Used  for  the  rank  of  the  user  account. 

5.  username:  String 

Used  for  the  user  name  of  the  user  account. 

6,  password:  String 

Used  for  the  password  of  the  user  account. 

7.  getLastNameQ 

Once  the  account  is  set  up,  this  method  will  be  used  to  retrieve  the  user’s  last 
name  from  the  database. 

8,  setLastNameQ 

This  method  will  be  used  to  set  up  an  account  in  the  database  with  the  user’s  last 

name. 

9.  getFirstNameQ 

Once  the  account  is  set  up,  this  method  will  be  used  to  retrieve  the  user’s  first 
name  from  the  database. 

10.  setFirstNameQ 

This  method  will  be  used  to  set  up  an  account  in  the  database  with  the  user’s  first 

name. 


11,  getGenderO 

Once  the  account  is  set  up,  this  method  will  be  used  to  retrieve  the  user’s  gender 
from  the  database. 

12,  setGenderO 

This  method  will  be  used  to  set  up  an  account  in  the  database  with  the  user’s 

gender. 


13.  getRankQ 

Once  the  account  is  set  up,  this  method  will  be  used  to  retrieve  the  user’s  rank 
from  the  database. 
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14,  setRankO 

This  method  will  be  used  to  set  up  an  aecount  in  the  database  with  the  user’s  rank. 

15,  getUserNameO 

Onee  the  aeeount  is  set  up,  this  method  will  be  used  to  retrieve  the  user’s  user 
name  from  the  database. 

16,  setUserNameO 

This  method  will  be  used  to  set  up  an  aeeount  in  the  database  with  the  user’s  user 

name. 

17,  getPasswordQ 

Onee  the  aeeount  is  set  up,  this  method  will  be  used  to  retrieve  the  password  from 
the  database. 


18,  setPasswordQ 

This  method  will  be  used  to  set  up  an  aeeount  in  the  database  with  the  user’s 
password. 

N,  RANK  AND  GENDER 

1,  getUniformsO 

This  method  will  be  used  to  get  the  Uniforms  HTML  page. 

2,  getAwardsO 

This  method  will  be  used  to  get  the  Awards  HTML  page. 

3,  getGroomingO 

This  method  will  be  used  to  get  the  Grooming  Standards  HTML  page. 

4,  getCivilianQ 

This  method  will  be  used  to  get  the  Civilian  ClothesHTML  page. 

5,  getPT_Gear() 

This  method  will  be  used  to  get  the  PT  Gear  HTML  page. 

6,  getMusicalQ 

This  method  will  be  used  to  get  the  Musieal  Organizations  HTML  page. 

7,  getOrganizationalO 

This  method  will  be  used  to  get  the  Organizational  HTML  page. 

8,  getRankInsigniaO 
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This  method  will  be  used  to  get  the  Rank  Insignia  HTML  page. 

9.  getHelpO 

This  will  be  a  function  that  allows  the  user  to  request  guidance  on  any  object  or 
function  that  may  be  unclear. 

10.  getManualQ 

This  will  list  the  current  versions  of  the  uniform  regulations  manuals  used  for  this 
web  site. 

11.  getContactQ 

This  will  display  the  contact  information  of  the  web  designer  and  manager.  This 
will  also  contain  contact  information  for  Marine  Corps’  uniform  regulations  department 
which  can  provide  answers  to  any  specific  uniform  item  questions. 

12.  getLinkQ 

This  is  a  generic  name  for  this  method  used  only  for  this  document.  The  actual 
site  will  contain  several  links  that  will  be  later  determined.  Each  link  will  require  a 
method  that  will  allow  the  web  browser  to  display  the  desired  link. 

13.  getMaleEnlistedIndexO 

This  method  will  be  used  to  get  the  index  page  for  the  Male  Enlisted  subcategory. 
This  will  allow  the  user  to  navigate  to  any  desired  rank  and  gender. 

14.  getFemaleOfficerlndexQ 

This  method  will  be  used  to  get  the  index  page  for  the  Eemale  Officer 
subcategory.  This  will  allow  the  user  to  navigate  to  any  desired  rank  and  gender. 

15.  getMaleOfficerlndexQ 

This  method  will  be  used  to  get  the  index  page  for  the  Male  Officer  subcategory. 
This  will  allow  the  user  to  navigate  to  any  desired  rank  and  gender. 

16.  getFemaleEnlistedIndexO 

This  method  will  be  used  to  get  the  index  page  for  the  Female  Enlisted 
subcategory.  This  will  allow  the  user  to  navigate  to  any  desired  rank  and  gender. 

O.  UNIFORMS 

Each  rank  and  gender  has  the  same  uniform  names  for  each  uniform. 
However,  the  uniforms  vary  for  each  rank  and  gender  while  the  names  are  shared.  The 
following  methods  will  get  the  correct  uniform  as  filtered  by  the  rank  and  gender. 

1.  getEveningAO 

This  method  will  get  the  Evening  A  HTME  page. 

no 


2,  getEveningBQ 

This  method  will  get  the  Evening  B  HTML  page. 

3,  getBlueDressAQ 

This  method  will  get  the  Blue  Dress  A  HTML  page. 

4,  getBlueDressBO 

This  method  will  get  the  Blue  Dress  B  HTML  page. 

5,  getBlueDressCQ 

This  method  will  get  the  Blue  Dress  C  HTML  page. 

6,  getBlueDressDQ 

This  method  will  get  the  Blue  Dress  D  HTML  page. 

7,  getBlueWhiteDressAQ 

This  method  will  get  the  Blue  White  Dress  A  HTML  page. 

8,  getBlueWhiteDressBQ 

This  method  will  get  the  Blue  White  Dress  B  HTML  page. 

9,  getServiceAQ 

This  method  will  get  the  Serviee  A  HTML  page. 

10,  getServiceBQ 

This  method  will  get  the  Serviee  B  HTML  page. 

11,  getServiceCQ 

This  method  will  get  the  Serviee  C  HTML  page. 

12,  getWoodlandO 

This  method  will  get  the  Woodland  HTML  page. 

13,  getDessertO 

This  method  will  get  the  Dessert  HTML  page. 

P,  UNIFORM  STYLES 

1,  getOptionalltemsQ 
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Each  rank  and  gender  has  different  optional  items  for  eaeh  uniform.  This  method 
will  be  used  to  get  the  optional  items  for  the  selected  uniform  as  filtered  by  the  selected 
rank  and  gender. 

2.  getDetailsQ 

Each  uniform  has  its  own  set  of  detailed  measurements  and  speeifieations  that  are 
also  dependent  on  rank  and  gender.  This  method  will  be  used  to  get  the  details  for  the 
seleeted  uniform  as  filtered  by  the  seleeted  rank  and  gender. 

Q.  TYPICAL  USE 

•  The  user  desires  the  measurements  of  a  particular  uniform. 

•  User  will  locate  web  presence  at  the  assigned  URL. 

•  User  will  log  in  with  user  name  and  password. 

•  The  system  will  filter  based  on  the  stored  rank  and  gender  for  the  user  and 
send  the  appropriate  subeategory  index  page  to  the  web  browser. 

•  The  user  will  select  “Uniforms”  from  the  navigation  bar. 

•  The  system  will  send  the  Uniforms  HTML  page  to  the  user’s  web  browser. 

•  As  the  user  is  scrolling  the  list  of  uniforms,  a  photograph  of  the  uniform  will 
be  displayed  in  the  “Uniform  Picture”  section. 

•  Once  the  appropriate  uniform  has  been  found,  the  user  can  search  the  detailed 
seetion  of  the  uniform  for  speeific  regulations  or  the  user  ean  view  the 
optional  items  for  the  selected  uniform. 

•  The  exact  text  from  the  MCO  will  be  displayed  in  the  text  area  for  eaeh 
seleeted  item. 

•  The  user  will  end  their  session. 

R.  DETAILED  DESIGN  LANGUAGE 

1,  HTML  Language  Choice 

Due  to  the  nature  of  the  web  page,  the  language  of  choiee  for  this  projeet 
will  be  Hyper-Text  Mark  up  Language  (HTML).  The  majority  of  the  pages  will  be 
eonstructed  using  this  language  with  additional  Java  Seript  being  used  as  neeessary. 

2.  HTML  Language  Definition 

The  following  table  identifies  the  basic  language  constructs  that  will  be  used  to 
develop  this  site. 
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A  HREF 

Identifies  a  hyperlink 

<A  HREF=”NAME” 

</A> 

APPLET 

Inserts  a  call  to  a 

JAVA  applet  into  an 
HTML  document 

<APPLET> 

</APPLET> 

BODY 

Outlines  body  text 

<BODY> 

</BODY> 

BR 

Line  break 

<BR>  </BR> 

CENTER 

Centers  text  between 
container 

<CENTER> 

</CENTER> 

DIV 

Identifies  division 
containers 

<DIV>  </DIV> 

FONT 

Sets  font  size 

<FONT>  <FONT> 

HI 

Identifies  a  level  one 
heading,  and  may 
contain  successive 
layers 

<H1>  </Hl> 

HTML 

Begins  the  HTML 

<HTML> 

</HTML> 

IMG  SRC= 

Identifies  inclusion  of 
an  image 

<IMG  SRC=”NAME”> 

LI 

Identifies  a  list  item 

<LI>  NO 

ENDING 

TITLE 

Identifies  the  title  of 
the  HTML  document 

<TITLE> 

</TITLE> 

SCRIPT 

Inline  script 

<SCRIPT> 

</SCRIPT> 

TABLE 

Creates  a  table 

<TABLE> 

</TABLE> 

TBODY 

Defines  the  tables  body 
when  headers  and 
footers  are  defined 

<TBODY> 

</TBODY> 

TD 

Provides  a  table  cell 

<TD>  </TD> 

TH 

Provides  table 
headings 

<TH>  </TH> 

TR 

Provides  a  table  row 

<TR>  </TR> 

Comments 

<!-  HI  THERE  -> 

SCRIPT 

Inline  script 

<SCRIPT> 

</SCRIPT> 

Table  1.  HTML  Tags 
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S.  DESIGN  AND  DEFICIENCY  MAINTENANCE 

1.  Deficiency  Prioritization 

Each  deficiency  that  is  found  will  be  prioritized  and  worked  on  according  to  time 
and  risk  faetors.  The  formula  used  for  this  assessment  follows: 

Estimated  Deficieney  Requirement  (DR)  Time  /  Total  DR  Times  =  DR  frequency 

ratio 

(DR  frequency  ratio  *  Priority)  *100  =  Risk  Eactor. 

During  the  initial  stages  of  the  project,  we  will  outline  a  cut  off  Risk  Eactor  of 
50%.  This  value  will  be  the  determining  threshold  by  whieh  defieiencies  will  be 
eorrected  and  implemented  into  the  project.  The  remaining  DR’s  from  the  cycle  will  be 
implemented  as  time  permits. 

2.  Deficiency  Risk  Analysis 

The  following  table  will  be  used  as  a  traeking  mechanism  to  ensure  DR’s  are  not 
overlooked  and  are  correeted  in  a  timely  manner.  This  ehart  will  be  used  to  prioritize 
deficieneies  noted  in  the  product,  apply  the  above  risk  formula,  and  correct  them  based 
on  risk  value. 


DR# 

DESCRIPTION 

EST 

HRS 

RISK  EREQ 

PRIORITY 

RISK 

Totals 

Table  2.  Risk  Matrix 

T.  EARLY  USABILITY  ANALYSIS 

1.  Description  of  analysis  subjects 

We  have  developed  paper  sketches  of  the  web  interface  to  be  used  in  this  early 
usability  analysis.  Two  subjects  were  chosen  for  the  initial  usability  test  of  the  web 
interfaee.  The  first  subject  was  a  civilian  NPS  student  with  no  military  experienee.  The 
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second  subject  was  a  Marine  1st  Lieutenant  with  five  years  of  military  experience. 
Subjects  of  widely  differing  backgrounds  and  military  experience  were  selected  in  order 
to  get  a  true  feel  for  the  usability  of  the  product.  There  was  no  user’s  manual  provided, 
however  the  website  gives  users  guided  instruction  on  available  options.  The  same 
prototype  sketch  was  given  to  each  subject  during  separate  analysis  sessions. 

2.  Rating  criteria  for  analysis 

The  HCl  design  and  judgment  criteria  as  set  forth  in  Section  C  of  this  document 
was  provided  and  explained  to  the  test  subjects.  The  subjects  were  asked  to  rate  the 
interface  on  a  scale  of  1-10  (1  being  poor,  and  10  being  excellent).  The  subjects  were 

also  given  the  option  to  rate  an  area  N/A  if  the  subject  felt  the  criteria  could  not  be  judged 

from  the  initial  usability  test.  Finally,  the  subjects  were  asked  for  any  feedback  outside 
the  focus  of  the  given  criteria. 

3,  Analysis 


CRITERIA 

RATING 

Ease  of  use 

9 

Quality  of  information  provided 

10 

Accuracy  of  information  provided 

N/A 

Interface  efficiency(i.e.  minimal  number  of  operations 
required  to  get  desired  info) 

10 

Error  free  design 

9 

Ease  of  navigation 

8 

System  help  function  adequate 

N/A 

Capability  to  satisfy  expert  users 

10 

Table  3.  Subject  1 


Subject  #1  was  the  civilian  NFS  student,  and  he  thought  the  interface  was 
extremely  well  done.  He  found  the  page  was  well  laid  out  with  nice  drop  down  menus 
and  links.  The  subject’s  inexperience  with  the  military  made  the  initial  navigation 
difficult,  but  he  felt  that  the  interface  was  designed  with  the  novice  in  mind.  This  attribute 
allowed  him  to  catch  on  quickly.  Additionally,  he  mentioned  that  the  presentation  of  the 
radio  buttons  used  on  the  second  to  last  interface  sketch  was  unclear,  specifically  on  how 
many  buttons  could  be  selected.  Overall,  he  gave  it  an  excellent  rating. 
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CRITERIA 

RATING 

Ease  of  use 

9 

Quality  of  information  provided 

10 

Accuracy  of  information  provided 

10 

Interface  efficiency(i.e.  minimal  number  of  operations 
required  to  get  desired  info) 

9 

Error  free  design 

9 

Ease  of  navigation 

8 

System  help  function  adequate 

N/A 

Capability  to  satisfy  expert  users 

9 

Table  4.  Subject! 

Subject  #2  was  the  Marine  1st  Lieutenant,  and  he  thought  the  interface  was 
extremely  well  done  as  well.  He  too  did  not  like  the  radio  buttons  used  on  the  second  to 
last  sketch;  he  would  prefer  drop  down  menus.  Additionally,  he  would  prefer  a  larger 
representation  of  the  uniform  insignia  presented  on  the  last  sketch.  He  commented  that  an 
interface  like  this  is  long  overdue.  Overall,  ha  gave  an  excellent  rating. 

4,  Conclusion 

The  initial  usability  test  was  a  very  positive  analysis  with  great  feedback  provided 
by  both  subjects.  Some  of  the  difficulties  encountered  during  testing  were  a  result  of 
utilizing  a  paper  interface  rather  than  a  real  GUI  interface  where  navigation  would 
potentially  be  more  intuitive  and  obvious  as  images  and  hotspots  appear.  All 
recommendations  will  be  considered  and  should  be  easy  to  fix  and  implement. 
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u. 


TABLE  OF  UNIFORMS 


Evening  Dress  A 


Male  Non  NCO 
N/A 


Evening  Dress  B _ N/A 

Blue  Dress  A  Just  like  NCO 

except 

without  blood 
stripe 


Blue  Dress  B 


Blue  Dress  C 


Just  like  NCO 
except 

without  blood 
stripe 


Blue  Dress  D 


Just  like 


Male  NCO 
N/A 


N/A 


Just  like 
Non  NCO 
except 
with  blood 
Stripe 


Male  SNCO 


Same  as  A 


Just  like 
Non  NCO 
except 
with  blood 
stripe 


Just  like 


Just  like 
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Male  Non  NCO 


Blue  Dress  C 
except  with 
short  sleeve 
and  no  hlood 
stripe 


Male  NCO 
Blue  Dress  C 
except  with 
short  sleeve 


Blue- White  Dress 


Male  SNCO 
Blue  Dress  C 
except  with 
short  sleeve 


_ B _ 

Service  A 

Note:  garrison 
cover  can  he  worn 
instead  of 
comhination  cover 
with  all  service 
uniforms 


Service  B 
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Woodland  Utility 


Dessert  Utility 


(Officer  Shown) 


(Officer  Shown) 


(Officer  Shown) 


Table  5.  Male  Enlisted  Uniforms 
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Evening  Dress  A 


Male  WO/Co  Grade 
Officer 


Same  as  Field 
Grade  except 
different  cover  and 
sleeve  device 


Male  Field  Grade 
Officer 


Male  Flag 
_ Officer _ 

Same  as  Field 
Grade  except 
different  cover  and 
sleeve  device 


Evening  Dress  B 

Note:  only 
difference 
between  A  and  B 
is  whit  waistcoat 
is  worn  with  A 
and  scarlet 
waistcoat  or 
cummerbund  is 
worn  with  B 
Blue  Dress  A 


Same  as  Field 
Grade  except 
different  cover 
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Blue  Dress  B 


Blue  Dress  C 


Male  WO/Co  Grade 
Officer 


Male  Field  Grade 
_ Officer _ 

Same  as  Company 
Grade  except 
different  cover 


Same  as  Company 
Grade  except 
different  cover 


Blue  Dress  D 


Same  as  Company 
— Grade  except 
^  different  cover 


Blue-White  Dress 
A 


Same  as  Company 
Grade  except 
different  cover 


Male  Flag 
_ Officer _ 

Same  as  Company 
Grade  except 
different  cover 


Same  as  Company 
Grade  except 
different  cover 


Same  as  Company 
Grade  except 
different  cover 


Same  as  Company 
Grade  except 
different  cover 
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Blue-White  Dress 
B 


Service  A 

Note:  garrison 
cover  can  be 
worn  instead  of 
combination 
cover  with  all 
service  uniforms 


Service  B 


Male  WO/Co  Grade 
Officer 


Same  as  Field 
Grade  except 
different  cover 
(unless  garrison 
cover) 


Same  as  Service  C 
except  with  long 
sleeve  and  tie 


Male  Field  Grade 
_ Officer _ 

Same  as  Company 
Grade  except 
different  cover 


Same  as  Co 
Grade  except 
different  cover 
(unless  garrison 
cover) 


Male  Flag 
_ Officer _ 

Same  as  Company 
Grade  except 
different  cover 


Same  as  Field 
Grade  except 
different  cover 
(unless  garrison 
cover) 


Same  as  Co 
Grade  except 
different  cover 
(unless  garrison 
cover) 


Service  C 


Same  as  Co 
Grade  except 
different  cover 
(unless  garrison 
cover) 


Same  as  Co 
Grade  except 
different  cover 
(unless  garrison 
cover) 
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Service  w  Sweater 


Woodland  Utility 


Dessert  Utility 


Male  WO/Co  Grade 
Officer 


Male  Field  Grade 
Officer 


Male  Flag 
Officer 


Table  6.  Male  Offieer  Uniforms 
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Female  Non  NCO 

Female  NCO 

Female  SNCO 

Evening  Dress  A 

N/A 

N/A 

Evening  Dress  B 

N/A 

N/A 

Same  as  A 

Blue  Dress  A 

Note:  all  Blue 
Dress  female 
uniforms  may  be 
worn  with  slacks. 
Non  NCO  slacks 
do  not  have  a 
blood  stripe. 

Same  as  Blue  Dress 

B  except  with 
medals 

Same  as  Blue 
Dress  B  except 
with  medals 

Same  as  Blue 
Dress  B  except 
with  medals 

Blue  Dress  B 

Blue  Dress  C 

Same  as  Blue  Dress 
D  except  with  long 
sleeve 

Same  as  Blue 
Dress  D  except 
with  long  sleeve 

Same  as  Blue 
Dress  D  except 
with  long  sleeve 
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Female  NCO 


Female  SNCO 


Blue-White  Dress 
A 


Same  as  Blue  Dress 
A  except  with  white 
slacks  or  white 
skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Blue-White  Dress 
B 


Same  as  Blue  Dress 
A  except  with  white 
slacks  or  white 
skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Service  A 

Note:  garrison 
cover  can  he  worn 
instead  of 
combination  cover 
with  all  service 
uniforms 


Service  B 
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Female  NCO 


Female  SNCO 


Service  w  Sweater 


Woodland  Utility 


Dessert  Utility 


(Officer  Shown) 


(Officer  Shown) 


(Officer  Shown) 


Table  7.  Female  Enlisted  Uniforms 
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Evening  Dress  A 


Evening  Dress  B 


Female  WO/  Co 
Grade  Officer 
Same  as  Field 
Grade  except  for 
different  sleeve 
insignia 


Same  as  A 


Female  Field 
Grade  Officer 


Same  as  A 


Female  Flag 
Officer 
Same  as  Field 
Grade  except  for 
different  sleeve. 
Also  scarlet 
waistcoat  and 
plain  front  shirt 
are  worn  by  Flag 
Officers, 


Same  as  A 


Blue  Dress  A 


Note:  all  Blue 
Dress  female 
uniforms  may  be 
worn  with  slacks. 


Blue  Dress  B 


Blue  Dress  C 


Same  as  Field 
Grade  except 
different  cover. 


Same  as  Field 
Grade  except 
different  cover. 


Same  as  Blue  Dress 
A  except  with 
ribbons  and  badges. 


Same  as  Blue 
Dress  A  except 
with  ribbons  and 
badges, _ 

Same  as  Co  Grade 
except  different 
cover. 


Same  as  Blue 
Dress  A  except 
with  ribbons  and 
badges, _ 

Same  as  Co  Grade 
except  different 
cover. 
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Blue  Dress  D 


Blue-White  Dress 
A 


Blue-White  Dress 
B 


Service  A 

Note:  garrison 
cover  can  he  worn 
instead  of 
combination  cover 
with  all  service 
uniforms 


Service  B 


Female  WO/  Co 
Grade  Officer 


(Enlisted  Shown) 


Same  as  Blue  Dress 
A  except  with  white 
slacks  or  white 
skirt. 


Same  as  Blue  Dress 
A  except  with  white 
slacks  or  white 
skirt. 


(Enlisted  Shown) 


Female  Field 
Grade  Officer 
Same  as  Co  Grade 
except  different 
cover. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Co  Grade 
except  with 
different  cover. 


Same  as  Co  Grade 
except  with 
different  cover. 


Female  Flag 
_ Officer _ 

Same  as  Co  Grade 
except  different 
cover. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Blue 
Dress  A  except 
with  white  slacks 
or  white  skirt. 


Same  as  Co  Grade 
except  with 
different  cover. 


Same  as  Co  Grade 
except  with 
different  cover. 
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Service  C 


Female  WO/  Co 
Grade  Officer 
Same  as  Field 
Grade  except  with 
different  cover. 


Service  w  Sweater 


Woodland  Utility 


Dessert  Utility 


Female  Field 
Grade  Officer 


Female  Flag 
_ Officer _ 

Same  as  Field 
Grade  except  with 
different  cover. 


Table  8. 


Fema 


e  Officer  Uniforms 
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III.  WEB  DESIGN  CHECKLIST 


Name: 

Date: 

Rank: 

MOS: 

Navigation 

There  is  a  clear  indication  of  the  current  location 

There  is  a  clearly-identified  link  to  the  Home  page 

All  major  parts  of  the  site  are  accessible  from  the  Home  page 

If  necessary,  a  site  map  is  available 

Site  structure  is  simple,  with  no  unnecessary  levels 

If  necessary,  an  easy-to-use  Search  function  is  available 

You  can  tell  where  you  are  immediately  (clear  title, 
description,  image  captions,  etc.) 

There  is  an  index,  table  of  contents,  or  some  other  clear 
indicator  of  the  contents  of  the  site. 

User  is  able  to  move  around  within  the  site  with  ease 

Directions  for  using  the  site  are  provided  and  are  easily 
understandable 

The  links  to  other  pages  within  the  site  are  helpful  and 
appropriate 

All  links  are  current 

Compliance 

Always  Sometimes  Never 

Notes 

Speed 

Compliance 

Always  Sometimes  Never  Notes 

No  unnecessarily  large  graphics  (slow 
download  time) 

Server  does  not  appear  to  be  slow  or  often 
inaccessible 

All  pages/links  load  in  a  timely  manner 

Design 

Compliance 

Always  Sometimes  Never  Notes 

ALT  tags  are  used  for  all  graphics, 
especially  navigation  graphics 

Black  text  on  white  background 
whenever  possible  for  optimal  legibility 
Plain-color  backgrounds  or  extremely 
subtle  background  patterns 

Text  is  in  a  printable  color 

Navigation  in  a  consistent  location 
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A  familiar  location  for  navigation  bars 
The  design  keeps  from  scrolling 

horizontally 

One  axis  of  symmetry  for  centered  text 
on  a  page 

Scrolling  is  encouraged  by  splitting  an 
image  at  the  fold 

There  is  sufficient  information  to  make 

the  site  worth  visiting 

The  information  is  clearly  labeled  and 

organized 

The  same  basic  format  is  used 
consistently  throughout  site 
Information  is  easy  to  find  (no  more  than 
three  clicks,  for  example) 

Lists  of  links  are  well  organized  and 
easy  to  use 

User  is  able  to  quickly  determine  the 
basic  content  of  the  site. 

User  is  able  to  determine  the  intended 
audience  of  the  site. 

The  language  used  is  simple  and 
appropriate  for  the  intended  users 
The  layout  is  clear 
Unnecessary  animation  is  avoided 


Information  Compliance 

_ Always  Sometimes  Never  Notes 

The  author(s)  of  the  material  on  the  site 
is  clearly  identified 

Information  about  the  author(s)  is 
available 

Author(s)  appears  qualified  to  present 

information  on  this  topic 

The  sponsor  of  the  site  is  clearly 

identified 

A  contact  person  or  address  is  available 
so  the  user  can  ask  questions  or  verify 
information 

Latest  revision  date  is  provided 
Content  is  updated  frequently 
The  purpose  of  this  site  is  clear: 
business/commercial,  entertainment, 
informational,  news,  personal  page, 
persuasion 

The  content  achieves  its  intended 
purpose  effectively 

The  content  appears  to  be  complete  (no 
“under  construction”  signs,  for  example) 

The  content  of  this  site  is  well  organized 
The  information  in  this  site  is  easy  to 
understand 
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This  site  offers  sufficient  information 

related  to  its  purposes 

The  content  is  free  of  bias,  or  the  bias 

can  be  easily  detected 

This  site  provides  interactivity  that 

increases  its  value 

The  information  appears  to  be  accurate 
based  on  user’s  previous  knowledge  of 
subject 

The  information  is  consistent  with 
similar  information  in  other  sources 
Grammar  and  spelling  are  correct 


Table  9.  Web  Design  Checklist 
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IV.  TESTING 


USMC  Web  Based  Uniform  Regulations 
Initial  Testing  Scenarios 


1 .  Please  state  your  name,  rank,  MOS,  and  years  experienee. 

2.  As  you  are  going  through  this  testing,  please  eomment,  positively  or  negatively, 
out  loud  regarding  some  of  the  following; 

a.  Overall  design 

b.  Color  seheme 

e.  Navigation 

d.  Aecuraey  of  the  information 

e.  Text  font  and  size 

f  Ease  or  diffieulty  of  using  the  site 

g.  Make  any  other  eomments  that  you  feel  will  be  helpful 

3.  Although  you  may  know  the  answer  to  the  following  seenarios  off  the  top  of  your 
head,  please  use  the  web  site  to  find  the  answers. 

4.  You  do  not  need  to  write  down  any  answers,  just  simply  keep  a  running  dialog  as 
you  are  working  through  the  seenarios. 

5.  What  is  the  size  of  the  hem  on  the  trousers  of  the  Serviee  Dress  C? 

6.  Where  does  the  Serviee  Badge  go  on  the  Evening  Dress  B? 

7.  Are  you  allowed  to  wear  a  flight  jaeket  with  the  Blue  Dress  D? 

8.  What  are  the  measurements  for  a  moustaehe? 

9.  Are  you  required  to  wear  ribbons  with  the  Serviee  Dress  B? 

10.  Where  does  the  USMC  emblem  go  on  the  pt  gear  sweatshirt? 

1 1 .  Eind  the  requirements  for  Eood  Serviee  Clothing. 

12.  When  are  you  required  to  wear  your  sleeves  up  on  the  Utility  uniform? 

13.  Please  feel  free  to  browse  the  site  as  you  wish  and  make  eomments  out  loud. 

14.  Please  fill  out  our  survey. 
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15.  Thank  you  very  much  for  participating  in  the  testing  of  this  site.  Your  input  is 
invaluable  to  the  functionality  and  success  of  this  web  site. 
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Name:  Test  Subject  1 

Date:  11  May  2006 

Rank:  Captain 

MOS:0602 

Navigation 


Compliance 


There  is  a  clear  indication  of  the  current  location 
There  is  a  clearly-identified  link  to  the  Home  page 
All  major  parts  of  the  site  are  accessible  from  the 
Home  page 


If  necessary,  a  site  map  is  available 

Site  structure  is  simple,  with  no  unnecessary  levels 

If  necessary,  an  easy-Io-use  Search  function  is 

available 

You  can  tell  where  you  are  immediately  (clear  title, 
description,  image  captions,  etc.) 

There  is  an  index,  table  of  contents,  or  some  other 
clear  indicator  of  the  contents  of  the  site. 

User  is  able  to  move  around  within  the  site  with  ease 
Directions  for  using  the  site  are  provided  and  are 
easily  understandable 

The  links  to  other  pages  within  the  site  are  helpful 
and  appropriate 

All  links  are  current 


Always  Sometimes  Never  Notes 

X 

X 

X  You  have  to  go  to 
rank/gender  page 
to  get  aceess  to 
the  real 
information 

X 

X 

X 

X 


X 

X  Links  were 

inaetive  during  the 
testing 

X 


Speed 

Compliance 

Always  Sometimes  Never  Notes 

No  unnecessarily  large  graphics  (slow 

X 

download  time) 

Server  does  not  appear  to  be  slow  or 

X 

often  inaccessible 

All  pages/links  load  in  a  timely  manner 

X 

Design 

Compliance 

Always  Sometimes  Never  Notes 

ALT  tags  are  used  for  all  graphics, 
especially  navigation  graphics 

Black  text  on  white  background 

X 

whenever  possible  for  optimal  legibility 

Plain-color  backgrounds  or  extremely 

X 

subtle  background  patterns 

Text  is  in  a  printable  color 

X 

Navigation  in  a  consistent  location 

X 

A  familiar  location  for  navigation  bars 

X 
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The  design  keeps  from  serolling 

X 

horizontally 

One  axis  of  symmetry  for  eentered  text 

X 

on  a  page 

Serolling  is  eneouraged  by  splitting  an 

image  at  the  fold 

There  is  suffieient  information  to  make 

X 

the  site  worth  visiting 

The  information  is  elearly  labeled  and 

X 

organized 

The  same  basie  format  is  used 

X 

eonsistently  throughout  site 

Information  is  easy  to  find  (no  more  than 

X 

three  elieks,  for  example) 

Lists  of  links  are  well  organized  and  easy 

X  No  active  links 

to  use 

User  is  able  to  quiekly  determine  the 

X 

basie  eontent  of  the  site. 

User  is  able  to  determine  the  intended 

X 

audienee  of  the  site. 

The  language  used  is  simple  and 

X 

appropriate  for  the  intended  users 

The  layout  is  elear 

X 

Unneeessary  animation  is  avoided 

X 

Information 

Compliance 

Always  Sometimes  Never  Notes 

The  author(s)  of  the  material  on  the  site 

X 

is  elearly  identified 

Information  about  the  author(s)  is 

Not  sure 

available 

Author(s)  appears  qualified  to  present 

1  don’t  know  about 

information  on  this  topie 

zee  German. 

The  sponsor  of  the  site  is  elearly 

1  don’t  know 

identified 

A  eontaet  person  or  address  is  available 

so  the  user  ean  ask  questions  or  verify 

information 

Latest  revision  date  is  provided 

Content  is  updated  frequently 

Don’t  know 

The  purpose  of  this  site  is  elear: 

X 

business/eommereial,  entertainment, 

informational,  news,  personal  page. 

persuasion 

The  eontent  aehieves  its  intended 

X 

purpose  effeetively 

The  eontent  appears  to  be  eomplete  (no 

X 

“under  eonstruetion”  signs,  for  example) 

The  eontent  of  this  site  is  well  organized 

X 

The  information  in  this  site  is  easy  to 

X 

understand 

This  site  offers  suffieient  information 

X 
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related  to  its  purposes 

The  eontent  is  free  of  bias,  or  the  bias 

X 

eati  be  easily  deteeted 

This  site  provides  interaetivity  that 

Not  vet 

inereases  its  value 

The  information  appears  to  be  aeeurate 

X 

based  on  user’s  previous  knowledge  of 

subjeet 

The  information  is  eonsistent  with 

X 

similar  information  in  other  sourees 

Grammar  and  spelling  are  eorreet 

X 

Table  10.  Test  Subject  1 
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Name:Test  Subject  2 


Rank:  Captain 


Navigation 

There  is  a  clear  indication  of  the  current  location 

There  is  a  clearly-identified  link  to  the  Home  page 

All  major  parts  of  the  site  are  accessible  from  the  Home  page 

If  necessary,  a  site  map  is  available 

Site  structure  is  simple,  with  no  unnecessary  levels 

If  necessary,  an  easy-to-use  Search  function  is  available 


You  can  tell  where  you  are  immediately  (clear  title,  description, 
image  captions,  etc.) 

There  is  an  index,  table  of  contents,  or  some  other  clear 
indicator  of  the  contents  of  the  site. 


Date:ll  May  2006 


MOS:  0602 _ 

Compliance 

Always  Sometimes 
Notes 


top 

User  is  able  to  move  around  within  the  site  with  ease  X 

Directions  for  using  the  site  are  provided  and  are  easily  X 

understandable 

The  links  to  other  pages  within  the  site  are  helpful  and  x 
appropriate 

All  links  are  current  x 
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There  is  sufficient  information  to  make  X 

the  site  worth  visiting 

The  information  is  clearly  labeled  and  X 

organized 

The  same  basic  format  is  used  X 

consistently  throughout  site 

Information  is  easy  to  find  (no  more  X 

than  three  clicks,  for  example) 

Lists  of  links  are  well  organized  and  X 


easy  to  use 

User  is  able  to  quickly  determine  the  X 

basic  content  of  the  site. 

User  is  able  to  determine  the  intended  x 

audience  of  the  site. 

The  language  used  is  simple  and  X 

appropriate  for  the  intended  users 

The  layout  is  clear  X 

Unnecessary  animation  is  avoided  X 


Information 


The  author(s)  of  the  material  on  the  site 
is  clearly  identified 

Information  about  the  author(s)  is 
available 

Author(s)  appears  qualified  to  present 

information  on  this  topic 

The  sponsor  of  the  site  is  clearly 

identified 

A  contact  person  or  address  is  available 
so  the  user  can  ask  questions  or  verify 
information 

Latest  revision  date  is  provided 
Content  is  updated  frequently 

The  purpose  of  this  site  is  clear: 
business/commercial,  entertainment, 
informational,  news,  personal  page, 
persuasion 

The  content  achieves  its  intended 
purpose  effectively 

The  content  appears  to  be  complete  (no 
“under  construction”  signs,  for  example) 
The  content  of  this  site  is  well  organized 
The  information  in  this  site  is  easy  to 
understand 

This  site  offers  sufficient  information 

related  to  its  purposes 

The  content  is  free  of  bias,  or  the  bias 

can  be  easily  detected 

This  site  provides  interactivity  that 

increases  its  value 

The  information  appears  to  be  accurate 
based  on  user’s  previous  knowledge  of 


Compliance 

Always  Sometimes  Never  Notes 


Didn’t  see  contact 
link 

unknown 


Uniform  man  unclear 


139 


subject 

The  information  is  consistent  with 

X 

similar  information  in  other  sources 
Grammar  and  spelling  are  correct 

X 

Inches  “ 

Table  11.  Test  Subject  2 


Name:  Test  Subject  3 

Date:  11  May  2006 

Rank.'LtCol 

MOS:7562 

Navigation 

Compliance 

Always  Sometimes  Never  Notes 

There  is  a  clear  indication  of  the  current  location 

X 

There  is  a  clearly-identified  link  to  the  Home  page 

X 

All  major  parts  of  the  site  are  accessible  from  the  Home 

X 

page 

If  necessary,  a  site  map  is  available 

X  Didn’t  see  one 

Site  structure  is  simple,  with  no  unnecessary  levels 

X 

If  necessary,  an  easy-to-use  Search  function  is  available 

X  Didn’t  see  one 

You  can  tell  where  you  are  immediately  (clear  title. 

X 

description,  image  captions,  etc.) 

There  is  an  index,  table  of  contents,  or  some  other  clear 

X 

indicator  of  the  contents  of  the  site. 

User  is  able  to  move  around  within  the  site  with  ease 

X 

Directions  for  using  the  site  are  provided  and  are  easily 

X  No  direetions 

understandable 

neeessary 

The  links  to  other  pages  within  the  site  are  helpful  and 

X 

appropriafe 

All  links  are  current 

X  Not  all  links 

operational 

Speed 

Compliance 

Always  Sometimes  Never  Notes 

No  unnecessarily  large  graphics  (slow 

X 

download  time) 

Server  does  not  appear  to  be  slow  or 

X 

often  inaccessible 

All  pages/links  load  in  a  timely  manner 

X 

Design 

Compliance 

Always  Sometimes  Never  Notes 

ALT  tags  are  used  for  all  graphics, 
especially  navigation  graphics 

Didn’t  notice 

Black  text  on  white  background 
whenever  possible  for  optimal  legibility 

X 

Plain-color  backgrounds  or  extremely 
subtle  background  patterns 

X 
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Text  is  in  a  printable  eolor 

X 

Navigation  in  a  eonsistent  loeation 

X 

A  familiar  loeation  for  navigation  bars 

X 

The  design  keeps  from  serolling 

X 

horizontally 

One  axis  of  symmetry  for  eentered  text 

X 

on  a  page 

Serolling  is  eneouraged  by  splitting  an 

No  horizontal 

image  at  the  fold 

scrolling 

There  is  suffieient  information  to  make 

X 

implemented 

the  site  worth  visiting 

The  information  is  elearly  labeled  and 

X 

organized 

The  same  basie  format  is  used 

X 

eonsistently  throughout  site 

Information  is  easy  to  find  (no  more  than 

X 

three  elieks,  for  example) 

Lists  of  links  are  well  organized  and  easy 

X 

to  use 

User  is  able  to  quiekly  determine  the 

X 

basie  eontent  of  the  site. 

User  is  able  to  determine  the  intended 

X 

audienee  of  the  site. 

The  language  used  is  simple  and 

X 

appropriate  for  the  intended  users 

The  layout  is  elear 

X 

Unneeessary  animation  is  avoided 

X 

Information 

Compliance 

Always  Sometimes  Never 

Notes 

The  author(s)  of  the  material  on  the  site 
is  elearly  identified 

Information  about  the  author(s)  is 
available 

X 

X 

Didn’t  see  addt’l  info 

Author(s)  appears  qualified  to  present 
information  on  this  topie 

The  sponsor  of  the  site  is  elearly 
identified 

X 

X 

Didn’t  see  a  sponsor 

A  eontaet  person  or  address  is  available 

X 

Didn’t  see  eontaet 

so  the  user  ean  ask  questions  or  verify 
information 

info 

Latest  revision  date  is  provided 

X 

Didn’t  see  one 

Content  is  updated  frequently 

The  purpose  of  this  site  is  elear: 
business/eommereial,  entertainment, 

informational,  news,  personal  page. 

X 

X 

Unknown 

persuasion 

The  eontent  aehieves  its  intended 

X 

purpose  effeetively 

The  eontent  appears  to  be  eomplete  (no 
“under  eonstruetion”  signs,  for  example) 

X 
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The  content  of  this  site  is  well  organized  X 
The  information  in  this  site  is  easy  to  X 
understand 

This  site  offers  sufficient  information  X 

related  to  its  purposes 

The  content  is  free  of  bias,  or  the  bias  X 
can  be  easily  detected 

This  site  provides  interactivity  that  X 

increases  its  value 

The  information  appears  to  be  accurate  X 
based  on  user’s  previous  knowledge  of 
subject 

The  information  is  consistent  with  X 

similar  information  in  other  sources 
Grammar  and  spelling  are  correct  X 

Table  12.  Test  Subject  3 


Name:  Test  Subject  4 _ 

Rank:Capt _ 

Navigation 

There  is  a  clear  indication  of  the  current  location 
There  is  a  clearly-identified  link  to  the  Home  page 
All  major  parts  of  the  site  are  accessible  from  the 
Home  page 

If  necessary,  a  site  map  is  available 

Site  stmcture  is  simple,  with  no  unnecessary  levels 

If  necessary,  an  easy-to-use  Search  function  is 

available 

You  can  tell  where  you  are  immediately  (clear  title, 
description,  image  captions,  etc.) 

There  is  an  index,  table  of  contents,  or  some  other 
clear  indicator  of  the  contents  of  the  site. 

User  is  able  to  move  around  within  the  site  with 
ease 

Directions  for  using  the  site  are  provided  and  are 
easily  understandable 

The  links  to  other  pages  within  the  site  are  helpful 
and  appropriate 


Date:  11  May  2006 _ 

MOS:  0180 _ 

Compliance 

Always  Sometimes  Never  Notes 
X 
X 
X 

X 

X 

X  Would  be  nice  to 
easily  find 

information 
X 

X 

X 

X 

X  Link  to  previous 

page  was  placed 
in  different 

locations 


Speed  Compliance 

_ Always  Sometimes  Never  Notes 

X 


No  unnecessarily  large  graphics  (slow 
download  time) _ 


Server  does  not  appear  to  be  slow  or 

X 

often  inaeeessible 

All  pages/links  load  in  a  timely  manner 

X 

Hard  to  sav  since  the 

pages  were  loeal 

Design 

Compliance 

Always  Sometimes  Never 

Notes 

ALT  tags  are  used  for  all  graphies, 

X 

Should  be 

especially  navigation  graphics 

descriDtive.  The  text 

on  a  few  of  the 

granhie  images  were 

diffieult  to  read 

Black  text  on  white  background 

X 

whenever  possible  for  optimal  legibility 

Plain-color  backgrounds  or  extremely 

X 

Good  water  marks 

subtle  background  patterns 

Text  is  in  a  printable  color 

X 

Navigation  in  a  consistent  location 

X 

Link  to  previous  page 

A  familiar  location  for  navigation  bars 

X 

The  baek  to  top  link 

was  buried  in  the 

bottom  of  the  page 

The  design  keeps  from  scrolling 

X 

horizontally 

One  axis  of  symmetry  for  centered  text 

X 

on  a  page 

Scrolling  is  encouraged  by  splitting  an 

Ignored 

image  at  the  fold 

There  is  sufficient  information  to  make 

X 

Referenees  speeifie 

the  site  worth  visiting 

items  in  text,  but 

forees  user  to  eonsult 

referenee 

The  information  is  clearly  labeled  and 

X 

organized 

The  same  basic  format  is  used 

X 

consistently  throughout  site 

Information  is  easy  to  find  (no  more 

X 

than  three  clicks,  for  example) 

Lists  of  links  are  well  organized  and 

X 

easy  to  use 

User  is  able  to  quickly  determine  the 

X 

basic  content  of  the  site. 

User  is  able  to  determine  the  intended 

X 

audience  of  the  site. 

The  language  used  is  simple  and 

X 

The  order  is  diffieult. 

appropriate  for  the  intended  users 

The  layout  is  clear 

X 

Unnecessary  animation  is  avoided 

X 
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Information 

Compliance 

Always  Sometimes  Never  Notes 

The  author(s)  of  the  material  on  the  site 

X 

is  elearly  identified 

Information  about  the  author(s)  is 

X 

available 

Author(s)  appears  qualified  to  present 

X 

information  on  this  topie 

The  sponsor  of  the  site  is  elearly 

X 

identified 

A  eontaet  person  or  address  is  available 

X 

so  the  user  ean  ask  questions  or  verify 

information 

Latest  revision  date  is  provided 

X 

Content  is  updated  frequently 

Under  Develonment 

The  purpose  of  this  site  is  elear: 

X 

business/eommereial,  entertainment, 

informational,  news,  personal  page. 

persuasion 

The  eontent  aehieves  its  intended 

X 

purpose  effeetively 

The  eontent  appears  to  be  eomplete  (no 

X 

“under  eonstmetion”  signs,  for  example) 

The  eontent  of  this  site  is  well  organized 

X 

The  information  in  this  site  is  easy  to 

X 

understand 

This  site  offers  suffieient  information 

X 

related  to  its  purposes 

The  eontent  is  free  of  bias,  or  the  bias 

X 

ean  be  easily  deteeted 

This  site  provides  interaetivity  that 

X 

inereases  its  value 

The  information  appears  to  be  aeeurate 

X 

based  on  user’s  previous  knowledge  of 

subjeet 

The  information  is  eonsistent  with 

X 

similar  information  in  other  sourees 

Grammar  and  spelling  are  eorreet 

X  Few  tvDOS 

Table  1 3 .  Test  Subj  ect  4 
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V.  XHTML  (HTML  AND  CSS)  CODE  EXAMPLE 


The  following  code  contains  the  full  CSS  style  sheet,  the  code  for  the  start  page 
and  exemplary  the  code  one  of  the  uniform  pages.  And  while  the  CSS  code  is  rather 
extensive  the  very  similar  HTML  of  the  start  page  and  the  Uniform  page  demonstrate  the 
simple  include  statements  used  to  assemble  the  output  HTML  files. 

A.  CSS 

body  { 

font-family:  Arial,  Helvetica,  sans-serif; 
color:#0A0A0A; 

background:  #F0F0F0  url(../images/Emblem_backgriund.gif)  no-repeat  fixed  0% 
65%  [important; 

background:  #F0F0F0  url(../images/Emblem_backgriund.gif)  no-repeat  scroll  -1% 

340px ; 

behavior:  url(/css/csshover2.htc); 

} 


*  {paddmg:0;margin:0;} 
table  { 

font-family:  Arial,  Helvetica,  sans-serif; 

font-size:  llpx; 

hne-height:15px; 

border- top :lpx  solid  #000000; 

border-right:  Ipx  solid  #000000; 

border-collapse:  collapse; 

} 

tr  { 

border:  Ipx  solid  #000000; 

} 

td{ 

paddmg:2px; 

border:  Ipx  solid  #000000; 

} 


#container  { 
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width:90%; 
min-width:  670px; 
margin:  lOpx  auto  auto  30px; 
border-top-width:  lOpx; 
border-top-style:  solid; 
border-top-eolor:  #0A0A0A; 
border-bottom-width:  lOpx; 
border-bottom-style:  solid; 
border-bottom-eolor:  #990000; 

baekground:  #FEFEFE  url(../images/Emblem_baokgriund.gif)  no-repeat  fixed  0% 
65%  [important; 

background:  #FEFEFE  url(../images/Emblem_backgriund.gif)  no-repeat  scroll  - 
35px  320px  ; 

} 

#logo  { 

margin:  Opx; 
padding:  Opx; 
height:  90px; 

background-attachment:  scroll; 
background- image:  url(../images/logo_mod.gif); 
background-repeat:  repeat-x; 
background-position:  left ; 
background-color:  #0A0A0A; 

} 

#Few_proud_logo  { 
float:  left; 

} 

#logo  #page_title  { 
float:  right; 
margin-right:  lOpx; 
padding-top :  3 . 5  cm; 

font-family:  Arial,  Helvetica,  sans-serif; 
font-style:  normal; 
font-weight:  bold; 
text-transform:  uppercase; 
color:  #FEFEFE; 

} 

#top_nav  { 

width:  100%; 
height:21px; 

background-color:#0A0A0A; 
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padding:Opx; 
float:  left; 

border-bottom-width:  lem; 
border-bottom-style:  solid; 
border-bottom-eolor:  #990000; 

} 

/*Only  for  the  start  page  weleome  banner*/ 

#navlist  { 

font-family:  Arial,  Helvetiea,  sans-serif; 

font-size:  12px; 

font-style:  normal; 

font-weight:  600; 

text-transform:  upperease; 

text-align:  eenter; 

letter-spaoing:0.07em; 

eolor:  #FEFEFE; 

margin- top:  3px; 

margin-bottom:  3px; 

} 

#breadorumb  { 

baokground-oolor:#990000; 
color:#FEFEFE; 
margin:  5px  Opx  2px; 
padding:  Opx; 
line-height:  normal; 

font-family:  Geneva,  Arial,  Helvetiea,  sans-serif; 
text-deeoration:  none; 
text-indent:  lOpx; 
font-size:  12px; 


#breaderumb  a  { 

eolor:  #FEFEFE; 
text-deeoration:  underline; 


#left_nav  { 

margin:  lemOemOem; 
padding:  Opx; 
float:  left; 
width:  20%; 
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} 

#pic_col  { 

float:  left; 
width:  55%; 
padding-top:  lOpx; 


#pic_col  .image_text{ 

margin-left:30%; 
font-size:.  8em; 

} 

#pie_eol  .image_text_small{ 
margin-left:30%; 
font-size:. 6em; 


} 


#pie_eol  .cover_pictures{ 
float:  left; 

} 

#pic_eol  .eover_pietures  p{ 
font-size:!  Ipx; 
margin-left:20%; 

} 


#right_eol  { 

width:20%; 
margin:  5px  Opx  Opx; 
padding:  Opx  3px  20px  5px; 
elear:  none; 
float:  right; 

font-family:  Arial,  Helvetiea,  sans-serif; 
font-size:  12px; 
font-style:  normal; 
font-weight:  normal; 

} 
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#details  { 

margin-bottom;  lOpx; 
padding:  Opx; 
font-size:  1.3em; 
display:none; 

} 

#details_local  { 

margin-bottom;  lOpx; 
padding:  Opx; 
font-size:  1.3em; 
display:none; 

} 

#optional_items  { 
margin:  Opx; 

font-size:  1.3em; 
display:none; 

} 

#detailed_text  { 

margin:  Opx  ; 
padding:  lOpx  30px  5px; 
elear:  both; 

font-family:  Arial,  Helvetica,  sans-serif; 

font-size:  14px; 

font-style:  normal; 

font-weight:  normal; 

font-variant:  normal; 

color:  #0A0A0A; 

border- top-width:  Ipx; 

border-top-style;  dotted; 

border-top-color:  #0A0A0A; 

list-style-position:outside; 

} 

#detailed_text  h3  { 

margin-top:5px; 

} 


#detailed_text  ol  li{ 

margin-top:5px; 

} 

#detailed_text  ol  li  ol  li{ 
margin-top:2px; 
list-style-position;  inside; 

} 
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#detailed_text  ol  li  ol  li  ol{ 
margin-left:  1  Opx; 
margin-top:2px; 
list-style-position:  inside; 

} 

#footer  { 

margin:  Opx; 

padding:  Opx  Opx  Opx  5px; 
eolor:#FFFFFF; 
baekground-eolor:  #0A0A0A; 
elear:  both; 

border-top-width:  thin; 
border-top-style:  solid; 
border-top-eolor:  #000000; 
height:  20px; 

} 

#eopy  p  { 

height:  100%; 
margin:  Opx; 
padding:  Opx; 

baekground-eolor:  #0A0A0A; 

olear:both; 

text-align:  left; 

float:  left; 

font-family:  Arial,  Helvetiea,  sans-serif; 

font-size:  12px; 

font-style:  normal; 

line -height:  normal; 

font-weight:  lighter; 

text-transform:  none; 

eolor:  #FEFEFE; 

vertieal-align:  middle; 

} 


_ 

/*  ext_links 

_ 


#ext_nav  #int_navlist  { 
float:  left; 
margin-left:  5  em; 

} 
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#ext_nav  #ext_navlist  { 
float:right; 
margin-right:  1  Opx; 

} 

#ext_nav  ul  { 

text-align:  center; 
background-eolor:  #0A0A0A; 
font-family:  Arial,  Helvetiea,  sans-serif; 

/*  line -height:  5px;  */ 

margin:  Opx;/*  fixes  Firefox  0.9.3  */ 
padding-top:  2px; 
padding-bottom:  2px; 
font-size:  12px; 

} 

#ext_nav  ul  li 

{ 

display:  inline; 
padding-left:  0; 
padding-right:  0; 
padding-bottom:  2px; 

/*  matehes  link  padding  exeept  for  left  and  right  */ 
padding-top:  2px; 

} 

#ext_nav  ul  li  a 

{ 

padding-left:  lOpx; 
padding-right:  lOpx; 
padding-bottom:  5px; 
padding-top:  5px; 
eolor:  #FEFEFE; 
text-deeoration:  none; 
border-right:  Ipx  solid  #EEEEEE; 
border-left-width:  Ipx; 
border-left-style:  solid; 
border-left-eolor:  #EEEEEE; 

} 

#ext_nav  ul  li  a:hover 

{ 

background-eolor:  #990000; 
color:  #EEEEEE; 
border:  thin  solid  #EEEEEE; 

} 
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I* _ */ 

/*  drop_down 

*! 

j* _ *j 


/*  the  horizontal  menu  starts  here  */ 
div#hstmenu  { 

width:  100%; 

font-size:0.75em;  /*  SET  FONT-SIZE  HERE  */ 

margin-top:2px; 

margin-bottom:  2px; 

z-index:  1; 

font-weight:  bold; 

} 

div#listmenu  ul  { 

margin:0  0  0  10%;/*  indents  ul  from  edge  of  eontainer  -  NOTE:  diff  value  for  IE 
in  haeks  below  */ 

} 

div#listmenu  li  { 

float:  left;  /*  eauses  the  list  to  align  horizontally  instead  of  staek  */ 
position:relative;  /*  positioning  eontext  for  the  absolutely  positioned  drop-down 

*/ 

list-style-type:none;  /*  removes  the  bullet  off  eaeh  list  item  */ 
baekground-eolor:#0A0A0A;  /*sets  the  baekground  of  the  menu  items  */ 
border-right:  Ipx  solid  #FEFEFE;  /*  ereates  dividing  lines  between  the  li  elements 

*/ 

z-index:  1; 

} 

div#hstmenu  li:first-child  { 

border-left:  Ipx  solid  #FEFEFE;  /*the  first  vertial  line  on  the  menu  */ 

} 


div#listmenu  li:hover  { 

baekground-eolor:#990000;  /*sets  the  baekground  of  the  menu  items  */ 
border-left-width:  Ipx; 
border-left-style:  solid; 
border-left-eolor:  #FEFEFE; 

} 

div#hstmenu  a  { 
display:blook; 

padding:2px  6px;  /*oreates  spaee  eaeh  side  of  menu  item's  text  */ 
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text-decoration:none;  /*  removes  the  underlining  of  the  link  */ 
color:#FEFEFE;  /*  sets  the  type  color  */ 

} 

div#listmenu  a:hover  { 
color:#FEFEFE; 

} 

/*  the  menu  ends  here  */ 

/*  the  drop-down  starts  here  */ 
div#listmenu  ul  li  ul  { 
margin:  Opx; 

z-indexilO;  /*  puts  drop-down  on  top  of  div  -  Safari  needs  this  as  menu  is  Ipx 
higher  */ 

position:  absolute;  /*  positions  the  drop-down  ul  in  relation  to  its  relatively 
positioned  li  parent  */ 

width:  lOem;  /*sets  the  width  of  the  menu  -  in  combo  with  the  li's  100%  width, 
makes  the  menu  stack*/ 

border-right:0;  /*  stops  SCBs  drops  having  two  right  borders  -  they  inherit  the 
border,  IE  doesn't  */ 

left:- Ipx;  /*aligns  the  drop  exactly  under  the  menu  */ 

} 

div#listmenu  ul  li  ul  li  {padding:0; 

width:  100%;  /*  makes  the  list  items  fill  the  list  container  (ul)  */ 
border-left:  Ipx  solid  #FEFEFE;  /*  three  sides  of  each  drop-down  item  */ 
border-bottom:  Ipx  solid  #FEFEFE; 
border-right:  Ipx  solid  #FEFEFE;} 
div#listmenu  ul  li  ul  li  a  {padding:  Ipx  .5em;} 
div#listmenu  ul  li  ul  li:first-child  { 

border- top:  Ipx  solid  #FEFEFE;  /*the  top  edge  of  the  dropdown  */ 

} 

/*  make  the  drop-down  display  as  the  menu  is  rolled  over  */ 

div#listmenu  ul  li  ul  {display :none;}  /*  conceals  the  drop-down  when  menu  not  hovered 

*/ 

div#hstmenu  ul  h:hover  ul  {display:block;  }  /*  shows  the  drop-down  when  the  menu  is 
hovered  */ 

/*  pop-out  starts  here  */ 
body  div#listmenu  ul  li  ul  li  ul  { 
position:  absolute; 

visibility:hidden;  /*  same  effect  as  display:none  in  this  situation  */ 

top:- Ipx; 

left:10em; 

} 

div#listmenu  ul  li  ul  li:hover  ul  {visibility:visible;}  /*  same  effect  as  display:block  in  this 
situation  */ 

/*  second  level  popouts  start  here*/ 
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div#listmenu  ul  li  ul  li:hover  ul  li  ul  { visibility :hidden;} 

div#listmenu  ul  li  ul  li  ul  liihover  ul  {visibility: visible;}  /*  same  effeet  as  display :bloek  in 
this  situation  */ 

/*  THE  HACK  ZONE  -  */ 

/*  haek  for  IE  (all  flavors)  so  the  menu  has  a  vertieal  line  on  the  left  */ 

*  html  div#listmenu  ul  { 

float:  left;  /*  makes  the  ul  wrap  the  li's  */ 

border-left:  Ipx  solid  #EEEEEE;  /*  adds  the  rightmost  menu  vertieal  line  to  the  ul 

*/ 

margin-left:5%;  /*  IE  doubles  the  given  value  above  -  why?  */ 

} 


/*  add  a  top  line  to  drops  and  pops  in  IE  browsers  -  ean't  read  :first-ehild  */ 
*  html  div#listmenu  ul  li  ul  { 

border- top:  Ipx  solid  #EEEEEE; 

border-left:Opx;  /*  stops  the  drop  inheriting  the  ul  border  */ 

} 


/*  the  Tantek  haek  to  feed  IE  Win  5. 5-5.0  a  lower  value  to  get  the  pop-out  to  touch  the 
drop-down  */ 

*  html  div#listmenu  ul  li  ul  li  ul  { 
left:9.85em; 
voice-family: 
voice-family:inherit; 
left:10em; 

} 

/*  and  the  "be  nice  to  Opera  and  Eirefox(ck)"  rule  */ 
html>body  div#listmenu  ul  li  ul  li  ul  { 
left:10em; 

} 


/*  an  Opera-only  hack  to  fix  a  redraw  problem  by  invisibly  extending  the  ul  */ 

/*  the  first-level  drop  stays  open  for  lOOpx  below  the  bottom  but  at  least  it  works  */ 

/*  this  can  be  reduced  to  as  little  as  22px  if  you  don't  have  pop-outs  */ 

/*  the  pop-out  menu  stays  open  for  22px  below  the  bottom  but  at  least  it  works  */ 

@media  all  and  (min-width:  Opx)  { 
body  div#listmenu  ul  li  ul  {padding-bottom:  lOOpx;} 
body  div#listmenu  ul  li  ul  li  ul  {padding-bottom:22px;} 

ul  li  ul  li  ul  li  ul  li:hover  {visibility: visible;}  /*  same  effect  as  display:block  in  this 
situation  */ 


} 

/*end  Opera  hack  */ 

/*  END  OE  HACK  ZONE  */ 

/*  the  drop-down  ends  here  */ 

/*  END  OE  EIST-BASED  MENU  */ 
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/*  finally  after  feeding  values  to  all  others,  we  deal  with  MAc5  IE  */ 

/*  IE5  Mac  can't  do  drop-downs  so  we  need  to  present  the  info  in  a  different  way*/ 

/*  we  present  the  drop  down  choices  in  a  row  and  never  show  any  second-level  drops  */ 

/*  this  stylesheet  is  read  by  IE5  Mac  only  -  hack  omits  'urf  and  leave  no  space  between 
@import  and  ("  */ 


_ 

/*  left_nav 

*/ 

_ 


.menu  { 

width:  75%; 

} 

#right_col  .menu{ 

margin-top:10px; 

fioatiright; 

} 


.menu  ul  { 

list-style:  none; 
margin:  0; 
padding:  0; 

} 


.menu  a,  .menu  h2  { 

font:  bold  16px  arial,  helvetica,  sans-serif; 

display:  block; 

border- width:  Ipx; 

border-style:  solid; 

border-color:  #ccc  #888  #555  #bbb; 

margin:  0; 

padding:  2px  3px; 

} 

.menu  h2  { 

color:  #EEEEEE; 
background:  #0A0A0A; 
text-transform:  uppercase; 

} 


.menu  #present{ 

color:  #EEEEEE  ; 
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background:  #990000; 
text-decoration:  none; 

} 

.menu  a  { 

eolor:  #FEFEFE  ; 
baekground:  #313643; 
text-deeoration:  none; 

} 


.menu  a:hover  { 

eolor:  #FEFEFE; 
baokground:#990000; 

} 

.menu  li  { 

position:  relative; 

} 

.lower_list{ 

margin-top:lem; 

} 


#validation  {position:relative; 

top:70px; 

left:30px; 


} 


I* _ */ 

/*  haeks  for  the  vertieal  nav  menu 

_ 


[iflE]> 

.menu  ul  li  {float:  left;  width:  100%;} 

<![endif] 

[if  It  IE  7]> 

.menuul  li  {float:  left;  width:  100%;} 
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.menuul  li  a  {height:  1%;} 


.menu  a,  .menu  h2  { 

font:  bold  0.7em/1.4em  arial,  helvetiea,  sans-serif; 

} 

<![endif] 

B,  HTML  AND  PHP  OF  START  PAGE 
1.  Index  Page 

<?php  SserverRoot  =  $_SERVER['DOCUMENT_ROOT'];  ?> 

<!DOCTYPE  html  PUBEIC  "-//W3C//DTD  XHTME  1.0  Transitional//EN" 
"http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> 

<!—  saved  from  url=(0014)about: internet  — > 

<html  xmlns="http://www.w3.org/1999/xhtml"> 

<head> 

<meta  http-equiv="Content-Type"  eontent="text/html;  eharset=iso-8859-l"  /> 
<title>The  Marine  Corps  Online  Uniform  Manual</title> 

<link  href="css/level_style.php"  rel=" stylesheet"  type="text/ess"  /> 


</head> 

<body> 


<?php  SincludeEile  =  $serverRoot.'/start_content.php'; 

if 

(fde_exists($includeEile)  &&  is_readable($ineludeEile)){ 

include($includeEile);  }  ?> 

</body> 

</html> 

2.  Content  of  start  page 

<?php  SserverRoot  =  $_SERVER['DOCUMENT_ROOT'];  ?> 


<div  id="container"> 

<div  id="logo"><a  name="pageTop"></a> 
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<div  id="Few_proud_logo"><img  src="images/Few_Proud_Logo.gif' 

alt="Few_Proud_Logo"  /></div> 

<div  id="page_title"><?php  $includeFile  =  'page  title.php'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 

include($includeFile);  }  ?></div> 

</div> 

<div  id="top_nav"> 

<?php  $includeFile  =  'banner.htm'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 
include($includeFile);  }  ?> 

</div> 

<div  id="left_nav"> 

<?php  SincludeFile  =  $serverRoot.'/navigation/left_nav.php'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 

include($includeFile);  }  ?> 

</div> 

<div  id="pic_col"><img  src="images/image.gif'  alt="image"  width="600" 
height="332"  /></div> 

<div  id="right_col"> 

<div  id="details"> 

<?php  SincludeFile  = 

$serverRoot.'/right_col_details/uniform_details.html'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 
include($includeFile);  }  ?></div> 

<div  id="optional_items"> 

<?php  $includeFile  =  $serverRoot.'/optionalItems/optional_items.htmr; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 

include($includeFile);  }  ?></div> 

</div> 
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<div  id="detailed_text"> 

<?php  $includeFile  =  'bottom_text/bottom.htm'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 
include($includeFile);  }  ?></div> 

<div  id="footer"> 

<div  id="copy"><?php  $includeFile  =  $serverRoot.'/copyright.php'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 
include($includeFile);  }  ?></div> 

<div  id="ext_links"><?php  $includeFile  =  $serverRoot.'/navigation/ext_liiiks.htm'; 

if 

(fde_exists($includeFile)  &&  is_readable($includeFile)){ 

include($includeFile);  }  ?></div> 

</div> 

</div> 


<div  id="validation"> 

<p> 

<a  href="http://validator.w3  .org/check?uri=referer"><img 
src="images/valid-xhtml  1 0.png" 

alt="Valid  XHTML  1.0  Transitional"  height="20"  width="66"  /></a> 


<a  href="http://www.php.net/"><img 

src="  images/php5  -power-micro  .png" 
alt="Powered  by  PHP  5.1"  /> 


</a> 

</p> 


</div> 


3,  Uniform  Page  Example 

<?php  SserverRoot  =  $_SERVER[’DOCUMENT_ROOT’];  ?> 

<!DOCTYPE  html  PUBEIC  "-//W3C//DTD  XHTME  1.0  Transitional//EN" 
"http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> 

<!—  saved  from  url=(0014)about: internet  — > 
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<html  xmlns="http://www.w3.org/1999/xhtml"> 

<head> 

<meta  http-equiv=" Content-Type"  eontent="text/html;  eharset=iso-8859-l"  /> 
<title>The  Marine  Corps  Online  Uniform  Manual</title> 

<link  href="oss/level_style.php"  rel=" stylesheet"  type="text/ess"  /> 


</head> 

<body> 


<?php  SineludeFile  =  $serverRoot.'/page_eontent.php'; 

if 

(fde_exists($ineludeFile)  &&  is_readable($ineludeFile)){ 

inelude($ineludeFile);  }  ?> 

</body> 

</html> 
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